Providing an ACH Payments Website Payments Solution can Provide Many Benefits for Various Organizations and Businesses. Here’s how to do it.
Providing ACH website payments solutions for organizations can include a multitude of requirements. Here at ACH Payments, we have a number of tools and integration methods that will likely meet the vast majority of organizations and businesses who have determined that they would benefit from accepting not just ACH payments from their website, but also credit card transactions. Let’s examine some key areas of interest for adding an ACH website payment solution:
Topics:
- Security and Integration
- User Experience
- Subscription Based Payments
- Pricing
- Reporting
- Conclusion
Security and Integration
Yes, we have all heard about the major retailers who have been compromised and credit card sata has been stolen. What we don’t hear about are the small websites that are compromised. Keep in mind that ACH transactions are not subject to the same PCI requirements that credit card transactions are, but nevertheless, both types of transactions contain sensitive data – and yes, bank account data from compromised websites is sold by data thieves and used nefariously by other unsavoury individuals.
In 2016, PC Magazine reported that almost 6,000 online shops had been compromised. While most of these shops that were compromised were using https or third party payment processors, those mitigation methods don’t protect against malicious javascript code injection. Malicious code is injected by security vulnerabilities and captures sensitive data that’s exposed.
Protection of sensitive data should be paramount to an organization who wishes to accept payments via their website. Above and beyond running on https, how the website payment integration communicates, or how the website payment utility being employed works is key to mitigating data theft.
Here at ACH Payments, we have utilities and integrations that can greatly reduce and even eliminate the risk of data theft; for both ACH transactions and credit card transactions. In all methods we have available, tokenization can be used. In some cases sensitive data never touches a using organization’s web server. Instead, sensitive data is posted directly to a PCI level 1 gateway which simultaneously returning a reference token that replaces the need to store the sensitive data. In such a scenario it’s completely impossible for nefarious intrusions to compromise sensitive data from the using organization’s web server.
There can be multiple options for integrating a payment solution for a website or web application. An API integration makes sense in many use cases, while a javascript modal utility can work quite well in a lot of use cases. The javascript modal utility prevents your webserver from ever touching or storing sensitive data, therefore reducing the PCI scope. While integrating with the API solutions does cause your webserver to initially touch sensitive data, that data is quickly replaced (a second or so) with a reference token to be used for subsequent transactions.
User Experience
How a payments page is presented to visitors is of great importance to organizations who want to accept payments via their website. Integration with the using organization’s database can allow for various fields to be populated upon arriving at the the actual payment submission page or modal, saving time from dealing with data errors submitted by visitors. Likewise, pre-populated data, whether visible or hidden, can make reconciliation a much simpler task, e.g., a hidden transaction number or account number.
Moreover, how the payments page appears to a visiting customer has a role in adoption. Redirection to a third party url might be fine for some organizations, but for others it simply doesn’t meet their needs. They know that a visiting customer must stay on their website URL and not be redirected for payment and then redirected back once the payment has been made.
The ability to allow and or control various options for payment acceptance can be beneficial to not only the visiting user, but also the integrated organization. For example, an organization with a recurring billing model might want the ability for the customer to configure their own recurring payments, but with limitations. An example of this might be that the consumer has a total payable amount of $300 that would be set as not editable, but there might be a choice allowed for the consumer to pay the total amount due over 2,3 or 4 months. Or, the total of $300 might be configured to be paid as either a single one-time transaction or split over 3 months – with the choice provided to the consumer. Other things like the start date of the transaction or the frequency can be editable if the integrating organization chooses to do so, e.g., pay monthly, bi-monthly or weekly.
No matter the use case, ACH Payments has you covered with a number of website payment options, from the aforementioned redirect to SOAP and RESTful integrations and javascript modals that transmit directly to the gateway.
Subscription Based Payments
Any organization that has a subscription based product or service that includes recurring payments generally has a need for ACH Payment acceptance. While many subscription based needs are setup manually by the merchant organization, some have the need for their visiting customer to setup the recurring payments themselves. Doing so requires that the integration or website utility used is capable of scheduling and managing recurring payments functionality.
Here at ACH Payments, we have the functionality for an organization to empower their website to accept, schedule and manage subscription, recurring based payments from their user base of customers.
ACH transactions are practically a must form businesses with recurring payments needs. Credit card declines average 15% in the recurring space. These declines come from expired credit cards, compromised or stolen cards and newly issued EMV cards. The amount of work that some organizations have to go through to re-capture new card data is a daunting task. While there are now tools to use like the credit card updater networks, there are transactional costs to those. Even then, the likelihood of all declines being updated is next to zero. Bank accounts don’t have expiration dates, and the percentage of rejected items from closed accounts in the subscription sector is far lower than credit card declines.
While a company must meet the need of their users in so far as what payment options are offered, having multiple payment modals is likely a wise choice – especially for a subscription based model. For example, having both a credit card and a checking account on file for customers can prevent wasted customer service time in chasing down new credit card information. Instead of chasing that credit card information down, the checking account could be debited if both accounts happen to be stored (as tokens).
Pricing
The costs from accepting ACH transactions is far less than accepting a credit card transaction. Given that the subscription sector knows their customers far better than a business’ website that is shaped more towards one-off transactions, ACH payments make a great deal of sense. Subscription based customers generally rely on the product or service being delivered by the business. In some cases it’s a delivery of a recurring item, and in other cases it’s a virtual service – which are easy to terminate access to, eliminating product loss revenues. Consider the cost difference: A subscription based business with 1,000 customers paying $75 per month via credit card amounts to ~$2,200 per month in processing costs. That same customer base using ACH would amount to ~$290 per month in ACH processing costs; an annual savings of ~$23,000.
Many ACH processors charge a percentage of the transaction amount to the ACH processing fee. In most cases, here at ach-payments.com, we charge a flat rate for transactions. This flat rate pricing becomes advantageous with average transactions amounts above $45. Below that amount it’s nearly identical for the bottom-line.
Of course we also offer credit card merchant accounts, and we certainly don’t want to downplay the importance of the credit card rail. It’s the most widely used form of electronic payments for websites. In some cases eCheck transactions simply don’t make sense for a given website. Pricing for credit card merchant accounts can vary slightly depending on the product or service sold and what the average sale ticket is. Pricing can be configured as tiered, interchange plus or as a flat rate.
Reporting
You need to know the status of your ACH transactions. There should be multiple methods for obtaining transaction status for reconciliation. Look for the ability to download multiple data formats in order to reconcile. Notifications are also important. Being able to assign users various permissions that send them email notifications are critical in instances such as NSF returned items. Moreover, notifications to customers can be very important.
How the reporting data gets back to your organization is likely important. In some cases it might be acceptable to download a daily or weekly file. But in some use cases it’s important to be delivered near instant status updates of the transaction cycle. That’s were employing webhooks can be advantageous. Webhooks are postback messages that are delivered to unique url’s that are configured for a given organization’s use case.
One huge advantage is being able to reconcile funding deposits to the transactions that comprised the bank deposit. Read more about Payment reconciliation.
Conclusion
If you are looking for a product or tool for accepting online payments, you have come to the right place. Our Secure Website Payments tools are easy to use, secure and can get you up and running quickly.
Some of the features included are:
- Merchant definable fields.
- Custom branding to match your site (hosted solution).
- REST API integration
- SOAP integration
- Javascript modal website payment utility
- Merchant controlled receipts and email notifications.
- Integrated webhooks for transaction event updates.
- Integrated reporting and reconciliation.
- Can accept both e-checks and credit cards.
- Option for future or recurring payments.
ACH Payments has been assisting businesses and organizations of all sizes with website payment integrations for over 20 years. If you’re looking for a solution for accepting payments on your website, contact us and we’ll guide you through the options and help you decide the best option for you and your company.
