2

3

What are the components of a subscription/payments processing system/platform?

Does anyone have a good explanation of how providers like Zuora, Authorise.net etc. come together?

flag
I added the tags for you. Really sucks that you can't do it yourself! We'll put in a feature request for that... Thanks for asking. – Jason Oct 11 at 1:31
Thanks for that! – anthon Oct 11 at 1:47

6 Answers

4

Here are the parts:

  1. Authorize.NET and such are "payment processors." They take credit card info and handle the authorization and fees with the card companies.
  2. You also need something called a "merchant account." This is the bank account where the processor deposits money. You'd think they could just deposit it into your standard checking account, but they don't.
  3. The credit card companies (Visa, Amex) talk to the processor so you don't have to do anything there.
  4. Fraud and chargebacks are also handled by the processor.

That's it!

If you use PayPal, that's all-in-one. They run the card and put in your PayPal account and you don't need the merchant account.

link|flag
So Zuora (and their main competitor escapes me right now) would be the same as Authorise.Net except their core competency is subscriptions, which is a subset of payments? – anthon Oct 11 at 1:48
I'd also add services like Spreedly.com as a separate component. They handle the creation of subscription billing schedules, and act as a front-end to your payment processor. – Jay Neely Jan 22 at 17:15
1

Here are the "parts" in a payments system: 1. A payment gateway - like Authorize.net is one example. There are many others... 2. Merchant Account - This is where the payment processing occurs. 3. Your normal checking account When your customers enter their credit card information on your shopping cart, the payment gateway provides a mechanism to route that transaction (it depends on your implementation of the shopping cart, but there can be different ways to route - route directly, route through your server, etc.) Your payment gateway will need to have your Merchant Account information, which is where they will route the information to. This tells your Merchant account provider, your payment processor to process the payment, i.e. charge the credit card of the customer and if approved settle it.. which means they deposit the money into your checking account.

Some providers are a one stop-shop, like the leading banks - BofA, Chase Paymenttech, etc. or you can work with these provider individually. To streamline the process, you might want a single vendor, but the biggest thing to keep in mind more than the $$, is the integration and support.

Hope this helps!

link|flag
1

Jason covers the lower layers pretty well. However, for subscription payments there's frequently an additional service - a "subscription processor". Examples in this space are Zuora and Spreedly.

Don't confuse some payment processors ability to do recurring payments with proper subscription processing - there are lots of edge cases around plan upgrades/downgrades, free trials, card changes, etc that the dedicated services do well.

link|flag
0

So does this sound like a subscription solution?

My application, interfacing through to Zuora/Aria to manage the subscriptions and then linking Zuora/Aria to Paypal who can then either provide the merchant account, or function as a gateway to a merchant account with a bank?

link|flag
0

Highly recommend PayPal; its easy to use and comprehensive. Besides their new API is plugging in countless third party apps that make it even more valuable; we just plugged in to automate bookkeeping and accounting for businesses using PayPal.

link|flag
0

Stay away from Zuora. It's not worth the headache. I tried the billing app, and it was just awful to integrate with our billing system. They seem to think they have a great product, but it's just hype with a headache.

link|flag

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.