Billing: Should I buy ready billing solution or built my own?

When building VoIP solution there is moment when you have this awesome service, but you need somehow to monetize all the hardwork. Then the inevitable question is here . Should integrated ready application or built my own. Tough integrating ready solution may seems more fast and easy, frequently this is not the case.  At the end of the day you will findout you need to build your own, because sometimes is even faster, especially when you need a lot of customization and ofcourse in that case would be cheaper too.

What about opensource billing solution?

that might be good option too. There is plenty of them http://www.voip-info.org/wiki/view/Open+Source+Billing+Systems , but again be careful at then you might still end qith need of complex solution, tough you can always use this as way to see how things (billing logic) can be done
Good option is to strat with open source billing system (especially if you have never deal with this before). Having the source code would give you a lot more flexibility and would let you do more things with it and remove things you don't need. You can always add more functionality, at then end you might end with solution which does not have much in common with the original.

Billing Systems vs. Payment Gateways

It is also important remember that these billing services are not payment gateways, they do not carry out the card transitions. They purely deal with the business logic of charges, re-charges, charge backs and data storage. In order to charge the card and for the money to end up in your account the billing service provider hooks into the API of your payment gateway of choice.

Essentially as a developer you have two options:
Option One
You choose to forward paying customers to the service’s hosted payment pages. This is the quickest and simplest way to get started. These pages are secure and accept query string parameters to pre-populate fields such as name and email address.
Successful payments will then be forwarded to a callback URL and any change to a subscription’s status will be posted back to your app via a post-back URL.
Both of these URLs are specified by you in the product settings of the billing service. Obviously, you would be mad not to validate the callback with a API query and likewise you will also need to check the nature of the subscription status change upon post-back notification.
Option Two
The process is almost identical to option one, however, you do not send users to the service’s hosted page to take payment. Your application collects (but does not store) all payment details and that data is then delivered to the billing service via their API.
In this instance the onus is upon you to take the user’s credit card details securely and handle the API’s response appropriately. However, the obvious benefits of this option is that the user’s experience is seamless, you have complete control over user interface design and user’s are unaware you’re using an external billing service.

Do i really need payment GW in my billing system?

In my practice when you have Softswitch solution with a lot of resellers, usually resellers bill their customers, using their billing systems, they also prefer to store credit info of end customers. But otherwise you would need yes.