So, you’ve been told you need to use Pay.gov to process payments. There are many decisions to make to get started, but the biggest is perhaps deciding how your system will interact with Pay.gov.
This post, which is the latest in MIL’s Pay.gov series, will address selecting the Pay.gov interface that’s best for you. MIL was the first organization to integrate Salesforce with Pay.gov and we hope that our experience will help to guide you through a successful transition.
Let’s get started. Pay.gov has three interfaces:
- A payment form managed by Pay.gov
- A web service integration where Pay.gov captures the payment information
- A web service integration where your system captures the payment information
Pay.gov Payment Form
The simplest integration is having Pay.gov create a payment form for your needs. You can choose the data fields you want to capture along with the payment types you want to allow. Payment forms presently in use can be found here.
The first page of the payment form process contains details about the person making the payment and, typically, their account number. The next page captures information about the payment itself, such as the payor’s bank account or credit card details. A confirmation page can then be shown to the user, offering a payment button for processing.
The big advantage of this approach is that you don’t need to do much. Pay.gov creates and manages the payment form pages for you. One downside, however, is your system doesn’t know anything about payments until after the fact. You find out about payments that have been made when you download the previous day’s transactions from Pay.gov. For each transaction, you can match up the account number for the payment with the account number in your system. However, if the user entered the account number incorrectly in the payment form, you’ll need to have a plan to deal with those cases.
Web Service Integration with Pay.gov Capturing Payment Details
A deeper level of integration can be achieved by having your system call Pay.gov through a SOAP web service, with Pay.gov capturing the payment information, and then redirecting back to your system.
The steps to follow for this integration are:
- Create a Payment ID. This will typically be an auto-incremented field because it must be unique to each payment
- Decide on redirect URLs for Pay.gov to use after payment authorization. One URL is used if the payment is successfully authorized and a different URL is used if it is not
- Call Pay.gov through a SOAP web service to get their unique identifier for the payment (known as a token). When calling the web service, you’ll need to pass in the Payment ID from your system, the amount to be charged, the ID of the account at Pay.gov to use (known as the TCS App ID), and the success and failure URLs. Pay.gov will return the token
- Redirect from your system to Pay.gov, passing in the token and the TCS App ID as parameters
Pay.gov will then display a page where the user can select the type of payment and enter in the payment details. Pay.gov will redirect back into your system using one of the two URLs you provided in step two, above. If the payment authorization failed or the user cancelled out of it, your page should allow the user to attempt payment again. If the payment authorization was successful, your page will need to make another SOAP web service call back to Pay.gov to confirm the payment. Once this returns a successful response, you can update your system that the payment was made.
When integrating with Pay.gov through this approach, the payment process is friendlier to the user than using the payment form. The user doesn’t have to enter an account number and details of the fields can be prepopulated when you redirect to Pay.gov. After payment authorization the user is also redirected back into your system, providing a much more seamless process.
Web Service Integration with Your System Capturing Payment Details
A final option for integration is to avoid showing any Pay.gov user interface. Your system can ask the user for the payment details and then make a SOAP web service call to Pay.gov to process the payment.
The advantage to this approach is that your system can maintain a user interface that is consistent between your normal system pages and payment pages. However, the downside is that your system is storing payment information, whether temporary or permanent. Ultimately, this can lead to additional work when your system is audited for government standards. It can also increase user apprehension about using your system, as they’ll need to provide their payment details to another entity.
Summary
Pay.gov has three interfaces that allow the processing of payments. Depending on factors of time and effort for the integration, your comfort level of storing payment information from users, and the need to provide a consistent user interface, you can make the best integration decision for your needs.
Cary Freeman is a force.com developer with 17 years of Java development and two years of Salesforce development. He holds 12 certifications, including a Salesforce Certified Application Architect, Salesforce Certified System Architect, and Project Management Professional (PMP).