OPTIMIZING MAGENTO PAYMENTS
Magento ships with a dozen payment methods by default, and there are numerous additional plugins available through Connect that support a wide range of wallets, gateways and process- es. Each of these solutions promises to exceed the others at achieving the singular goal of shepherding customers past the last step in the checkout process. Making sense of the options requires mapping business requirements, and as such, developing a baseline understanding of the currently available features and their inherent limitations is crucial in optimizing the e-com- merce checkout flow.
Accepting credit card payments (which often represents the vast majority of transactions) re- quires establishing a gateway account, and usually additionally requires opening a merchant bank account. These are frequently confused as the same, mostly because gateways will sometimes proxy as merchants in setting up the necessary deposit account, however the dis- tinction is important as they bear on an important choice: gateways authorize credit card trans- actions and merchant accounts receive the transferred funds.
When setting up gateway and merchant accounts, the main (initial) consideration is whether the gateway recognizes your business as the merchant of record, or if it is acting as an aggregator (i.e. processing through it’s own account and disbursing funds after the fact). While it is easier to set up an aggregated account, it is often more costly in the end as aggregators must account for the additional degree of risk that they assume when acting on behalf of their customers.
For businesses that are processing above $1M annually, we strongly recommend becoming a merchant of record as it generally minimizes transactional costs and potential reserve spikes.
Most gateways are able to process the same four types of transactions, each of which is rele- vant to specific use cases:
- Sale. The “sale” transaction is the most basic, comprising a single call that initiates a single charge on a customer account. This type of transaction usually returns a transaction ID, which can be used for administrative purposes.
- Authorization. The “auth” transaction is used to query a customer account for available funds and block an amount for future use. This type of transaction usually returns an auth ID, which can be used when executing the transaction.
- Capture. The “cap” transaction is used to complete a transfer that has been previously autho- rized against a customer account. This type of transaction usually takes an auth ID and re- turns a transaction ID.
- Subscription. The “sub” transaction is used to set up a series of transactions, according to a schedule (i.e. weekly, monthly or yearly). This type of transaction usually returns a sub ID.
Many merchants process one-off payments as direct sales, which is usually fine, as long as it is reasonably certain that items will ship within a matter of days. However, allowing a relatively long window between the charge and ship processes can lead to discomfort, service calls and negative perception (potential fraud is always a customer concern). For digital downloads, we recommend immediate capture, but for physical products we recommend authorizing on order and capturing when items are ready for shipment (i.e. just before they leave the warehouse). This minimizes the customer’s perceived risk while preventing a scenario wherein items are shipped against uncapturable funds.
Fraudulent transactions originating from stolen credit card numbers or otherwise account for roughly 1% of e-commerce volume and can significantly impact bottom line. There are a suite of features available to counteract potential fraudsters, including:
- AVS. AVS checks the first few characters of the billing address string and the billing zip against the address of record, which is good practice.
- CVV. Checking for CVV generally ensures that the user is in physical possession possession of the card, as it is not allowed to save this data, and is a good practice.
- 3-D Secure validation. 3-D (or 3-domain) validation inserts a provider-managed interstitial page into the checkout process that often requires a provider login to continue. In theory, this is is a good additional layer of security, but in practice becomes quite cumbersome and can diminish conversions.
- Black lists and white lists. Generally compared with GEO IP values, known lists can block users from offending geographic locations (such as an office array or an entire country), while enabling seemingly fraudulent transactions from known locations (such as internal develop- ment and testing). Again, this requires ongoing monitoring to avoid wholesale order blocking.
- Velocity checks. Brute force hacks frequently employ automated attempts to circumvent secu- rity measures, which can be countered with velocity throttles. Generally, this is a good idea, assuming your business does not have frequent reorders within narrow windows.
- Device fingerprinting. Prevent frequent reorders from specific devices as well as GEO IP loca- tions and check headers for authentic device identification. Ibid, above.
- Rule scoring. Many gateways and fraud prevention services implement a rule scoring mech- anism that weighs the accumulated positive checks against the negative and empowers the merchant to set an acceptable threshold. This can be a useful device, but needs ongoing at- tention to optimize conversions.
When servicing a global customer base, it is important to factor in local expectations when con- figuring payment options, including payment base currencies and payment terms.
- Currency setup. Magento can be configured to display a converted fronted currency or to match fronted and backend currencies by website. The latter is often a better approach, as it allows the site operator to set marketing-friendly prices in each currency (i.e. $9.99 vs. $9.73).
- Payment type. Different regions have different expectations regarding payment terms (i.e. Brazilians prefer layaway while Germans prefer COD). Additionally, many local economies use specific payment types (i.e. prepaid cards) which should be considered, both in terms of customer support and any additional transactional costs or liabilities. A few examples of pay- ment methods that we have seen (beyond the standard credit vs. debit) include prepaid, trans- fer, miles, invoice and installments.
Saving any kind of payment data to a local database requires PCI-DSS certification, which is always an ongoing, time-consuming and expensive process (think quarterly 3rd party system- wide audits). For this reason (as well as the significant related liability issues), we have always steered clients away from this option.
Instead, we recommend leveraging gateway tokenization, which empowers customers to reuse cards that they save to a profile while shifting PCI liability from the merchant to the gateway. In this way, merchants simply store a hashed string (or “token”) that allows them to access card credentials that have been stored in an external repository.
E-wallets are a form of tokenization that allow users to store their card details once and then provide access to merchants as needed. The main advantage to users is security, but the solu- tion also provides convenience, particularly when checking out on a mobile device where typing a card number is cumbersome.
From a merchant perspective, if implemented properly e-wallets present little downside. The only concern is limiting the number of available payment methods so as to prevent checkout overload. For example, we like Paypal and Google Wallet in most cases, and we are looking forward to a device-specific solution for iOS devices that leverages Apple Pay.
There are a number of excellent gateways that integrate with Magento, each of which offer dis- tinct services. While an exhaustive list is out of scope for this document, there are a few that we like for specific use cases:
- FirstData: FirstData is the largest processor in the United States and can generally provide highly competitive rates, for both online and in-store processing.
- Linkpay. Linkpay provides excellent support for a range of local payment methods, which can convey to improved conversions and lower transactional costs for businesses that do signifi- cant business cross-border.
- Authorize.net. Authorize.net provides excellent API support for custom application develop- ment as well as a solid tokenization solution.
- Paypal. Paypal used to be under the same corporate umbrella as Magento, as such there are a number of integrations baked into the platform that make it an easy add-on.
- Stripe. We like Stripe for low-volume merchants, as they provide both account aggregation and strong API support.