This article is courtesy of Idealware, which provides candid information to help nonprofits choose effective software. For more articles and reviews, go to www.idealware.org.
It can be hard to understand how online payment processing works. Many different steps and a lot of jargon make it seem more complicated than it is. To help you see the big picture, we've laid out a typical payment process in diagrams.
Here's the whole diagram for a reference. Then we'll break it down into individual parts.
The Visitor Front End
Let's start by considering the payment pages that your visitors see. A payment page on your website allows visitors to select and define what they are paying for, instigate the payment process, and then enter credit card numbers and the other information necessary to validate payments. For mobile payments, such as those through apps like Square or PayPal Here, the payment page is the app itself — you enter the information as the party accepting the payment instead of the visitor.
First, visitors need to choose what they are paying for — for example, a donation, product, or registration for an event. For donations, this might be as straightforward as providing a "Donate" button, but selling products or events often involves complex functionality to show visitors what is available and to let them select what they want (for instance, via a "shopping cart"). If you're selling products, you'll also need to think about calculating shipping and taxes. The mechanics of products, events, and shopping carts could each fill up an article of their own, so for now let's assume that your visitors have selected what they want and have a fixed price they'd like to charge to their credit card.
With a price defined, the next step is for them to fill in a payment form with their information: name, credit card information, and address, at a minimum. Once they've entered their information and clicked "Submit," a number of back-end processes kick off. Payments made with mobile apps work more like cash registers than online forms. You'll typically enter the item or event being paid for and swipe the person's card, and they'll sign and approve the payment. Then, the back-end processes begin.
The Payment Gateway and Fraud Prevention
The first process is a check to try to verify that the credit card and the charge are valid.
When your visitors click "Submit," a processor called the Payment Gateway takes over. The Payment Gateway — the little man in red in the diagram — handles the actual back-end communications and transactions: contacting the bank, reporting back on the results, and moving the money.
The Payment Gateway starts by checking to make sure that the credit card number is valid. To decrease the possibility of fraud, it may also check to make sure that the address, name, and card security code — the three-digit code on the back next to the name strip — match. Unfortunately, fraud is common even if you're just processing donations, so these verification checks are an important step in the process.
If the card is rejected, the Payment Gateway sends word to your website or mobile device so you can notify the visitor. If it is verified, the process continues.
In the next step, when the charge is accepted as valid, the Payment Gateway initiates a process to transfer money from the credit card company to a type of specialized bank account called a Merchant Account.
A Merchant Account does nothing but hold credit card payments, but you can't accept credit cards without one. Even if you have one for accepting credit card payments by phone, you may need a different one for online payments.
You can open your own Merchant Account through your bank or one recommended by your payment processor, or you can use a vendor's. For instance, if you accept payments via PayPal, you are relying on PayPal's Merchant Account. Like any bank account, you'll want to shop around — rates vary. These accounts define the base amount you'll pay for each transaction. You'll need a Merchant Account whether you are accepting payments online or through a mobile app, but in the case of a mobile app, you'll typically use the vendor's.
Thanks, Receipt, and Reports
With the payment successfully processed, the visitor is notified that their payment went through, and the transaction is viewable in reporting tools.
When the payment gateway reports back that the card has been charged, visitors are shown a confirmation screen confirming that everything went through successfully. They are also typically emailed receipts at this point. Usually, any reports are updated in real time to let you see within seconds that a payment was made.
Now you'll need to determine how to get the payment data from the payment processor into your own database.
The reporting tools that automatically show the payment information are not likely to be the same application you use to track constituent information, so in order to synch the two sources, you should be able to at least manually export a text file from the payment processing application and load that into your database. If you plan to process many transactions, it's worth looking into ways to automatically synch the two data sources with the help of a programmer.
Receiving the Money
Last but not least, the money needs to be moved from the Merchant Account to your bank account.
While it's in the Merchant Account, the payment isn't accessible to you. If the Merchant Account is in your name, however, rather than a vendor's, the money will automatically be deposited into your bank account within a couple of days. If the Merchant Account is in a vendor's name, that vendor needs to pay you — they typically make payments once or twice monthly, either via check or by wire transfer.
Putting It All Together
Here's the complete diagram again showing the entire process.
While payment processing is not a simple, straightforward procedure, it doesn't have to be baffling. None of the steps are particularly technical or complicated, and they're all within reach of even the smallest nonprofit. You just need a sense of the big picture.