The ability to process payments online is an essential feature of any e-commerce application or Web site. Mobile or Web apps that have some paid features or services also need the ability to collect one-time or recurring fees.
Online payment processing services allow you to process credit or debit cards along with other forms like PayPal or even manual invoices in a secure and automated manner. This article provides an introductory overview of the basics of online payment processing.
Payment Gateways and Merchant Accounts
The typical transaction flow when using a payment service to process an online transaction is shown in the diagram below:
According to Wikipedia, a payment gateway is a e-commerce application service provider that authorizes credit card and other types of payments for e-business, online retailers or traditional brick and mortar stores.
In order to accept payments by card, you, as a business, will need to have a merchant account, which is a special type of bank account.
For every credit or debit card transaction, a payment gateway contacts the customer’s card issuer to check for sufficient funds. If the funds are successfully verified, they are transferred to a merchant account, which holds the payments until they are transferred to a normal business bank account.
Every merchant that accepts credit card payments needs to comply with Payment Card Industry Data Security Service (or PCI DSS for short) rules. Depending on how your application transfers sensitive customer data to the payment gateway, your bank will require you to complete different self-assessment questionnaires:
With Slides, we don’t make you start from an empty slate. All you have to do is to pick the elements you like best and combine them. Each slide has been carefully crafted to satisfy three key criteria: aesthetic, function and usability. That way you know every element works together seamlessly while enhancing the impact of your content.Learn MoreOther Products
- PCI DSS Self-Assessment Questionnaire C if cardholder data is passed through your backend servers. When cardholder data passes through your hosting environment, even though you are not storing it, your systems fall within the scope of PCI compliance.
- PCI DSS Self-Assessment Questionnaire A or PCI DSS Self-Assessment Questionnaire A-EP if cardholder data is passed straight to the payment gateway servers and is never sent or stored on your servers.
Please note that the information above is for reference only and comes without any guarantee. If you have any questions regarding PCI compliance, please contact one of the Qualified Security Assessors.
As you can see, online payment processing is a complicated field. There are many services that promise to make it easier for a startup to begin accepting payments. Selecting right payment service for your application might be a challenge. You should pay attention to the capabilities provided, the integration experience and, of course, the prices and fees.
Over the course of this article, we’ll take a look at three popular payment processing services and what they can offer for your application. These services are:
Stripe and Braintree set you up with the processing gateway and a merchant account. Recurly, on the other hand, is a bit different from the other two because it does not provide either of these.
While both Stripe and Braintree offer the ability to collect recurring payments along with processing one-time transactions, Recurly puts subscription management functionality first and allows you to choose your payment gateway.
The set of features a particular payment service provides defines the number of potential customers you can reach.
The wider the variety of payment methods and currencies supported, the easier it is for a customer to pay for your products or services.
Currencies and Payment Types
Aside from supporting one-time transactions, most payment services offer recurring billing functionality. This allows you to implement a subscription business model and offer your customers a variety of tiers (subscription plans).
Payment processing typically requires changes both on the client- and server-side. A client app needs to provide some sort of UI for selecting a product or a service, and for entering payment details like customer name, address and payment card information. On the server-side, an application might need to have control over when and what transactions are going through, support features like trials, discounts, complex pricing structures, analytics and reporting, etc.
To make the integration experience as easy and quick as possible, it’s important to make sure that the payment service offers libraries and support for all client and server platforms your applications run on (or might run on in the future).
Having a well documented REST API is a big plus because even if a vendor does not offer official libraries for your platform of choice, it’ll be fairly easy to implement one yourself. There is also a good chance that some community-maintained implementations already exist.
Collecting Payment Details
When integrating with a payment service, it’s important to understand how customer data is collected and transferred to a service provider.
It is highly advisable to avoid ever sending any kind of sensitive customer information to your servers while processing a transactions unless it’s absolutely necessary for your business logic to be able to access that kind of data. It’s better to send that data directly to a payment service and let the service provider securely handle and store it. It is their business, after all. This approach also reduces your PCI compliance requirements.
To avoid this, your client application needs to somehow collect and pass the payment details directly to the service API. This can be done in two ways:
- The payment form can be hosted on the service provider side. In this case, your client application will need to redirect a the customer to the service Web site to complete their transaction. Vendors often offer customization options to make that Web site fit your design, but they are usually fairly limited. On the plus side, that approach is very straightforward and easy, requiring minimal changes to the client code.
- The payment form can be hosted in your application. It can either be a custom form or a form that is generated by a vendor’s library. That way you are free to customize the look and feel of the form and have a full control over the user experience.
In the second case, the form that accepts payment information is typically submitted to the payment service (instead of your backend). The service securely stores customer information and returns a token that identifies that information but cannot be used to reverse-engineer the payment details. This token can be then be used by your client- or server-side to complete transactions in place of that sensitive data.
When implementing this approach, be sure that it’s not possible to make arbitrary API calls to the payment service directly from the client, especially if it is a Web application. The client should only be responsible for acquiring a token, while all other communication (like determining the price to charge) should be performed by your backend.
Alternatively, if a client makes the API calls, you should make sure that the call arguments can not be tampered with.
The ability to test your code in a safe sandbox before releasing it to production is a must, especially when it comes to anything money-related.
Most payment services give you a testing environment or mode in which you can simulate successful and failed payments to see how your application handles various situations that can arise.
It’s also important to be able to test out your webhook and notification handling logic, so any capabilities that simplify that process are welcome.
It’s difficult to overrate the value of good documentation. A clear, full and logically organized documentation center is important. How else would you gain an understanding of how the payment service works, and what your options and the best practices are?
Payment services tend to have different cost structures, which usually are a combination of per-transaction, monthly and setup fees and can be based on the volume of payments being processed.
It’s important that you understand the pricing structure of a payment service before you choose one. Transparent and predictable costs are vital for your business.
Please note that in the case of Recurly, you pay separately for your payment gateway and merchant account in addition to Recurly service (although, Recurly Gateway is free).
If you are interested primarily in recurring billing, here is a cost calculator, that you can use to estimate and compare these three services (among others).
Over the course of this article we took a quick look at how to process online payments and also compared three payment processing services. All of these provide a robust set of features and are able to securely accept payments on your behalf.
Stipe and Braintree offer similar simple pricing structures and set you up with a payment gateway and a merchant account, so you don’t have to worry about choosing them yourself. Both are solid choices for accepting one-time payments. Subscription functionality is also supported, but Stripe provides a bit more flexibility than Braintree in that respect. A lack of publicly exposed REST API may limit your platform options if you go with Braintree, but if their official libraries cover all what you need, this is not much of a concern.
Recurly is a service primarily devoted to subscriptions. It offers the most flexible recurring billing functionality across the three, including specialized reports and sales tax calculations. It does however require you to have a merchant account and to select a payment gateway, both of which may require additional payments, which somewhat complicates their cost structure. Recurly does support one-time payments, but if your business model does not involve customer subscriptions, Stripe or Braintree might be a better option for you.