Payments is a critical part of any e-commerce system. Integrating with a new payment processor is often full of unknowns for developers, and the documentation is either too cumbersome and time-consuming or, on the contrary, scanty and, to the extent it is available, tends to focus only on technical details.

The aim of this article is to provide a primer on the key concepts and terminology of online card payments as well as shed some light on the payment integration and related complexities. It provides brief context on the payment system and key regulatory principles and best practices you need to know before designing and implementing the payment module. We also covered the oft-forgotten edge cases you need to handle for large e-commerce solutions. You will learn what to expect and how to address the payment-related issues and problems.

Authors

My name is Rauf Aliev. I am a solution architect at EPAM Systems. Almost ten years ago, I worked for Chronopay, one of the largest payment service providers in Russia. As a Head of Development, I was responsible for internal development projects and was involved in PCI DSS formal assessments. Since then, the topic of payments in e-commerce has been developing in details, but the core concepts remained largely the same. My co-author, friend, and colleague, Aleksey Kryuchkov, Software Engineer at EPAM, helped with how card payments have to be handled properly (based on his working experience with the large retail company in Russia), and what collisions and edge cases with card payments the large online store can face. Before joining EPAM, Aleksey had been working for more than eight years as a Head of Development at the Russia’s second-largest retailer, Svyaznoy (I worked for Svyaznoy too, together with Aleksey, also in the role of Head of Development, but two years before).

Table of contents

• 1. Payment Processing in the nutshell
  • 1.1. Parties
  • 1.2. Anatomy of a Credit Card Number
  • 1.3. Payment Processing
• 2. Credit Card Transaction Process
• 3. Payment Authorization
  • 3.1. Card Authorization Process
  • 3.2. Zero Amount Authorizations
  • 3.3. Authorization Validity Time Limit
• 4. Payment Clearing and Settlement (Charge)
  • 4.1 Late Capture
• 5. Fees that Affect Rates
• 6. Payment reversals
  • 6.1. Authorization Reversal
  • 6.2. Chargebacks
  • 6.3. Refunds
    • 6.3.1. Partial Refunds
    • 6.3.2. Refunds for Digital Products
    • 6.3.3. Returns for Transactions in A Foreign Currency
    • 6.3.4. Costs of Refunds For Merchant
• 7. 3-D Secure and Liability Shift
• 8. Recurring Payments and Subscriptions
  • 8.1. Handling Stored Credentials
• 9. Integration methods
  • 9.1. Direct Integration (API)
  • 9.2. Hosted Order Page (HOP)
  • 9.3. Silent Order Post (SOP)
• 10. Common pitfalls and challenges
  • 10.1. Duplicate payments
  • 10.2. Incorrect currency conversion
  • 10.3. Incorrect Merchant Code
  • 10.4. Expired Authorization
  • 10.5. Expired Web Session
  • 10.6. Failed Notification Webhooks
  • 10.7. Abandoned Carts (because of no payment)
  • 10.8. Split/Partial Payments
  • 10.9. Reasons why the payment can be declined
• 11. Payments in SAP Commerce
  • 11.1. What’s Coming Out of the Box
  • 11.2. Payment Process
  • 11.3. Payment data model in SAP Commerce
  • 11.4. SAP Commerce Payment Module Architecture
• 12. What is next? Web Payments Standard from W3C is coming

1. Payment Processing in the nutshell

1.1. Parties

The basic participants of the card payment process are the following:

• Merchant is a company who sells goods or services to a cardholder. Behind all e-commerce websites, there is at least one merchant account for the payment gateway(s) these systems are integrated with. The merchant account number is used to identify a financial institution that acts as a transaction acquirer for the merchant.

• Cardholder is the person to whom the credit card is registered, and, normally, whose name is printed on the card.

• Acquiring Bank (or acquirer or merchant’s bank) is the maintainer of the bank account of the merchant and authorize and process credit card payments on behalf of merchants. Each acquiring bank has connections to a limited number of payment service providers.

• Issuing Bank (or credit card issuer) is a bank-issuer of the customer’s debit or credit card. It maintains the bank account of the customer associated with the card.

• Settlement Bank is an institution authorized to execute settlement or interchange on the credit card payment processing system. It is normally located in the country where settlement currency is the local currency.

• Payment Card Networks manage communications between banks and regulate the relevant processes in the banks and payment service providers by developing industry standards and supervises the card processing operations in banks and payment service providers. Examples are Visa and MasterCard (act as trade associations), Discover and American Express (act as the issuing banks)

• Payment Service Provider (PSP or IPSP) is the company who handles the details of processing credit card transactions between merchants, issuing banks, and merchant account providers and communicates with the issuing banks to authorize and settle complete credit card transactions. Sometimes the PSP is an arm of the acquiring bank.

How these parties operate with one another is shown below.   Payment aggregation allows one company to process or facilitate payments on behalf of smaller merchants. Payment aggregators (also known as facilitators) may be integrated with various payment service providers and function as a “one stop shop” for a merchant. They allow merchants to accept payments without having to set up a merchant account. Such payment aggregators as Google Checkout and Amazon Payments support more than differ in their payment aggregator approaches, costs, and services delivered to merchants. A few examples of payment aggregators are Citrus, CCAvenue, and PayUMoney. Technically, such giants as Stripe, PayPal and Square fall into this category as super-aggregators.

1.2. Anatomy of a Credit Card Number

The card numbering system follows the ISO IEC 7812 standard For credit and debit Visa/MC cards, the number contains 16 digits, but there are variants for other payment systems. First six digits stands for the issuing bank ID, next nine digits is card account number. The last digit is a check digit.

1	2	3	4	5	6	7	8	9	10	11	12	13	..	..	LAST
industry	IIN/BIN (bank ID)					PAN, customer account number (1-12 digits)									Check digit
From 8 to 19 digits

This check digit is calculated as a simple checksum modulus 10 (Luhn’s algorithm). The first digit identifies the major industry of the card issuer:

• 0 — ISO/TC 68 and other industry assignments
• 1 — Airlines
• 2 — Airlines, financial and other future industry assignments
• 3 — Travel and entertainment – American Express, Diners Club
• 4 — Banking and financial – VISA
• 5 — Banking and financial – Mastercard
• 6 — Merchandising and banking/financial – Discover Card
• 7 — Petroleum and other future industry assignments
• 8 — Healthcare, telecommunications and other future industry assignments
• 9 — For assignment by national standards bodies

For the sake of accuracy it is worth mentioning that some cards have a different number of digits, from visa Electron to local cards, such as Mada or Meeza. These card networks are not covered in the article.

1.3. Payment Processing

The key components (capabilities) of payment processing are the following: The details on what is what are explained in the sections below.

2. Credit Card Transaction Process

The transaction process can be broken down into two stages:

1. Authentication and Authorization. In the authorization stage, the merchant obtains approval for payment from the issuing bank.

2. Clearing and Settlement. In this stage, the transaction is posted to both the cardholder’s credit card statement and the merchant’s statement.

Payment Service Providers provide mechanisms to perform authorization and capture in one go. The authentication/authorization and clearing/settlement process is known as the “4-party model”, because the merchant, the acquiring bank, the payment card network, and the issuing bank are involved. This model applies to Visa/MasterCard transactions. For other networks, such as American Express and Discovery the model are simpler: the network and the bank is the same entity. The process for such cases is known as “3 party model”.

3. Payment Authorization

Authorization is requested when a customer makes a purchase. This authorization is provided by the customer’s issuing bank and confirms the card holder’s validity, the ability to pay, and the presence of sufficient funds etc. Once this is completed, funds are held and the balance is deducted from the customer’s credit limit but is not yet transferred to the merchant account.

3.1. Card Authorization Process

In the authentication stage, the issuer verifies the validity of the customer’s credit card.

1. Customer submits the card details to the payment service provider (via payment form)
2. Credit card details are sent to the acquiring bank and credit card network for approval.
3. The credit card network clears the payment and requests payment authorization from the issuing bank.
4. The issuing bank validates the credit card number, checks if funds are available on account, matches the billing address to the one on file and validates the CVV number. There are also fraud protection rules on both the bank’s and PSP’s side.
5. The acquiring bank delivers the result to the merchant.
6. The issuing bank also places a hold in the amount of the purchase on the cardholder’s account.

For the fraud prevention purposes, there are various mechanisms performed during this step including:

• Address Verification Check. The system checks if the customer provides the correct billing address. If a customer provides incorrect information, the transaction might be marked as fraudulent and authorization requires might be rejected.
• Card Verification Number Check. The system checks the validity of the CVN printed or embossed on the back of the card against the value stored in the issuing bank. Visa calls it the Card Verification Value (CVV2), Mastercard calls it the Card Validation Code (CVC2).

Some banks support zero-amount authorizations. This operation shows if a payment card account is valid and if the card is lost or stolen. For the same purpose, some services authorize the smallest amount ($1) and releases it immediately afterwards.

3.2. Zero Amount Authorizations

Some processors support zero amount authorizations. Such authorizations are used to check card validity. Not all payment service providers support zero amount authorizations.

3.3. Authorization Validity Time Limit

There is a timeframe between when a transaction is authorized and when it is submitted for settlement. For Visa, the default expiration time frame is 7 days for normal transactions, and 24 hours for recurring transactions and some kinds of businesses (restaurants, taxis and some other). For the travel-related business models the time frames are extended (31 days) to allow more flexibility. For Mastercard, the default expiration time frame is 30 days for normal transactions, and 7 days for recurring transactions. Issuing banks can extend these time frames at their own discretion. In SAP Commerce Cloud, the default payment interface doesn’t have any functionality to keep expiration time frame under control. You need to customize it if such a need arises.

4. Payment Clearing and Settlement (Charge)

In the clearing and settlement stage, the issuer posts the transaction to the cardholder’s account.

1. At the end of each business day, the approved authorizations are sent in a batch to the acquiring bank or processor.
2. The acquiring processor forwards them to the credit card network for settlement.
3. The credit card network routes each approved transaction to the appropriate issuing bank.
4. The acquiring bank credits the merchant’s account for cardholder purchases
5. The issuing bank posts the transaction to the cardholder’s account.

4.1. Late Capture

A capture does not happen in real time. All of the capture requests are sent to the processor as a batch at the end of the day. It usually takes 2-4 days for the acquiring bank to deposit funds in your merchant bank account. The second reason for the delay is make-to-order products and pre-ordered products when the merchants can take advantage of the gap between when funds are being held in the card holder’s account but not yet transferred to the merchant account. The capture request is supposed to be sent not immediately but when the product is ready for delivery. The alternative way, with refunds, can be too risky and/or costly for the merchant. Due to one of these potential delays, the authorization request might expire before you request capture. You might be required to resubmit an authorization request, but for this operation you need to get authorization approval from the client again. This edge case is often not implemented in e-commerce solutions by default. The issuing bank and payment service provider may have different expiration times for the authorization transactions. When the transaction is expired in the issuing bank, the payment service processor and the merchant are not normally notified.

5. Fees that Affect Rates

Discount rate – to acquirer. The merchant’s acquiring bank charges a fee and collects a percentage of every transaction. Typically this fee runs between 1% and 3% depending on the nature of the transaction. This fee depends on the contract terms and service subscription details and comprises of three components:

• Interchange fee – to issuers. This fee is paid to the issuing banks. The interchange fee is specific to the payment networks (Visa fees and Mastercard fees) and regulated by them. The rates change twice a year, in April and October. Typically, this fee is comprised of a percentage to the issuing bank plus some fixed amount to the credit card network (for example, 2.35% + $0.15). The average interchange rate for credit cards is normally higher than one for debit cards. For VISA, the rates for large banks (“regulated”, banks with over $10 billion in assets) are much lower than for smaller ones (“exempt”). The final discount rate for the merchant can’t be lower than the interchange fee.
• Assessments – to VISA/MC. These fees are paid directly to the Visa or MasterCard. The assessment fee is usually based on a percentage of the total transaction volume for the month. For example, VISA may charge a 0.10% assessment + $0.018 processing or usage fee for transaction.
• Markups – PSP/acquirer. The PSPs and acquirer banks make money by putting a markup on top of the rates above. This is called cost-plus or interchange-plus pricing.

6. Payment reversals

6.1. Authorization Reversal

The authorization reversal (cancellation, void) operation releases the amount held via the authorization request. It is normally used for the situations when a customer cancels the order before the order amount is settled or the availability check showed that the product or service cannot be delivered to the customer. If a customer notices something incorrect after submitting the payment form, and the charge operation has not happened yet, the customer can call their bank to stop the transaction from occurring. However, this scenario creates might be problematic for the merchant because the issuer’s bank doesn’t notifies the merchant or their processing service provider about the change. However, authorization reversal initiated by a customer is preferable over a future chargeback or refund. The merchant can cancel the authorization by sending the reversal command to the processing center for the particular transaction. The blocked amount will be quickly released. Not all payment service providers support merchant-initiated authorization reversals. SAP Commerce Cloud: The authorization reversal operation is implemented via PaymentService.cancel(transactionEntry). It is part of standard accelerator order management process (cancelOrderAction). By default, this implementation is mocked. SAP Commerce also provides OrderCancelPaymentServiceAdapter interface which is mocked by default too.

6.2 Chargebacks

Customers can dispute a charge within 60 days of the statement date. Then the process of interaction between the issuing bank and the merchant is started. As a result, a decision is taken to return funds for the disputed charge – this is a chargeback. Merchant’s banks (acquirers) get slapped with extra fees when their clients breach a chargeback threshold ratio. Having too many chargebacks can mean the imposition of restrictions and possibly even the loss of the merchant account associated with the issue. If the customer escalates their issue to the bank, the merchant is immediately charged an irreversible fee (of about $20) simply as an administrative fee for a chargeback processing. That is why most sellers prefer to know about the problem before the bank receives a billing dispute. When the issuing bank receives a customer complaint, it contacts the merchant and requests the details via the Sales Draft Requests. If no reply within a certain timeframe or poor proof, the bank issues the chargeback which is covered automatically from the merchant’s account or when no funds by the merchant’s bank. The issuers are interested in appeasing their cardholders. When their customers file a chargeback, banks tend to assume honest intent rather than a fraud attempt. Additionally, payment systems have chargeback monitoring programs and categorize the merchants based on the chargeback count and chargeback-to-sales ratio. For example, in Visa, monthly 500 chargebacks and 2% ratio will lead to get categorized as a high-brand risk merchant. It should be followed by stopping the service. If you have a legitimate problem with a purchase and want your money back, better ask the merchant to resolve the issue before you get their bank involved and request a chargeback. Very likely, your case will be resolved faster. For the merchant, losing out on revenue might not be optimal, but it’s far better than ending up with a chargeback that might cost the same amount of revenue anyway — plus fees. Chargeback regulations were developed many years ago and largely obsolete now. They weren’t designed to accommodate the purchasing options we have today.

6.3. Refunds

A refund is an operation voluntarily initiated by the merchant. It allows returning the whole or part of the transaction amount to the customer. Most merchants allow the customers to receive a refund back to the credit card they made the original purchase with. If the original card is expired, the refund procedure may become challenging. The merchant cannot know that your new card is in fact a replacement for the old one. The refund operation is also not free for the merchant (as well as handling returns). However, the average refund costs are normally included in the price of a product to keep things balanced. However, there is a risk of double refunds that happen when a customer contacts both the merchant and the issuing bank about the disputing transaction, and the merchant approves a refund while the bank, at the same time, initiates a chargeback. Because of the communication gap and delayed processes, a merchant is unaware that a chargeback process has started. This case, along with disputing the transaction when the merchant’s service is not reversible, also known as “friendly fraud”. The best way to reduce the risk of friendly fraud and double refunds is not to skimp on communication with the client and payment service provider. Also, it is important to have a well-settled public policy the customer agrees with before making the purchase. A refund will not usually post to the customer’s credit card account instantly. So it is important to notify the user about the refund to avoid the double refund situation.

6.3.1. Partial Refunds

Partial refunds are used for situations in which a customer orders multiple products, and the customer has decided to return only some items. In our experience, the partial refunds weren’t allowed by the return policy. If a customer wanted to exclude one or more positions from the placed order, the original order was completely replaced with a new one. In SAP Commerce, the default refund calculation doesn’t take into account the customer group or the promotion lifecycle. The default refund strategy assumes that when a promotion is published, it will never be changed. This default strategy is easily understandable for the end user, but it also poses some limitations which should be taken into account during development. If there is a promotion applied to the order, and the promotion is changed or disabled since the order is placed, the new promotion conditions won’t be reflected in refund amounts according to the default strategy. For example, the customer has an expensive mobile phone and a cheap phone case in the same order. After placing the order and receiving the product, the customer returns the phone so that the actual order contains only a case delivered for free. If the customer bought only the case from the very beginning, the delivery would not be free because of the free delivery threshold. After the phone was excluded from the order, the delivery remains free. So this causes additional costs for th merchant to be incurred.

6.3.2. Refunds for Digital Products

Refunds can be requested for many reasons. The downloaded software product may not function as expected at the customer side or it is not compatible with the user’s setup. The customer may just change their mind and decide that the product is no longer needed for them. The refund request can be filed for poor quality. In all cases, the product has already been delivered, and cannot be returned back to the seller like a physical product.

6.3.3. Returns for Transactions in A Foreign Currency

This is another area that can be complicated. Many credit cards charge a foreign transaction fee. This fee is not refundable, and it’s possible the customer won’t get that fee back when they make a return. Theoretically, this fee can be refunded by the issuer if the customer makes a request for that, but I haven’t heard of any successful cases.

6.3.4. Costs of Refunds For Merchant

Each refund is also not free for the merchant. Some providers agree to return the refunded interchange to the merchant and charge only a small fee to route the refund. Some providers keep the interchange fee and charge only a transaction fee. And some not only keep the interchange fee but additionally charge the processing fee and transaction fee on the refund. Some providers also charge an address verification fee. So there are many ways on how to losing money on refunds and you need to clarify the payment service provider’s fee policy.

7. 3-D Secure and Liability Shift

3-D Secure (Three-Domain Secure, 3DS) — often known by its branded names like Visa Secure, Mastercard Identity Check, or American Express SafeKey — is a messaging protocol to enable customer to authenticate themselves with their card issuer. This technology was designed to protect acquiring banks from friendly fraud explained above in the Chargebacks and Refunds. Normally, merchants are liable for fraudulent transactions. With 3-D Secure in play, the responsibility for fraud is shifted from the merchant on the issuing bank or even to the cardholder. If a cardholder attempts to dispute a 3DS transaction by claiming that it was made without their consent, the issuer will close the dispute and refuse a chargeback. 3-D Secure stands for Three Domain Secure. The domains mentioned in the name are

• merchant/acquirer domain (an e-shop)
• issuer domain (a customer’s bank)
• the interoperability domain (payment system)

(the diagram is from Wikipedia with some amendments) A very simplified 3-D Secure process is as follows (numbered steps are depicted at the diagram):

1. The Customer enters their card information (card number, expiration date, CVV/CVC etc.)
2. Payment Service Provider (PSP) contacts a Directory Server (for Visa, Visa Directory) to check whether the card is enrolled in 3-D Secure (participating in the Verified by Visa program or Mastercard SecureCode).
3. If enrolled, Directory Server sends a Verification Request (VEReq) to the issuer’s Access Control Server. This request is resulted in Verification Response.
4. If verification is not possible, the request results with “Cardholder not Enrolled” или “Authentication not available”, and the Customer is redirected to the standard flow (not 3-D Secure). If verification is possible, Access Control Server sends issuer’s 3-D Secure form (URL) in the response.
5. Directory Server sends the Verification Response (with the URL of 3DS or without) from the previous step to 3-D Secure Merchant Plug-in, the component installed on the merchant’s side (in the e-shop).
6. The merchant plugin redirects the cardholder to the URL received in the response.
7. The Customer (cardholder) authenticates themselves to the issuing bank on the 3D Secure page by entering a code from the text message or accepts the request in the bank app. The 3-D Secure authentication mechanisms vary in different banks. For local payments, the text messages or push notifications are used. The customer receives a one-time password (code) in the message.
8. The result of this authentication attempts is recorded into Authentication History Server. These records can be used later for dispute resolutions.
9. Access Control Server digitally signs the Authentication Response and sends it to the merchant plugin.
10. Merchant Plugin checks the response against the certificate and initiates the Auth request following the standard procedure. The Payment Service Provider submits the card information and the 3D Secure authentication result to the PSP’s acquiring bank.
11. The Acquiring Bank authorizes the transaction by contacting the credit card network and issuing bank
12. The Payment Service Provider redirects the customer back to the merchant’s website, to a success or error page.

Some Payment Service Providers implement the various add-ons, such as

• Full 3-D Secure. The payments are accepted only if 3-D Secure flow is successfully passed. However, large retailers tend to dislike 3-D Secure, as it is seen to have a negative impact on online conversion rates and lead to decreasing sales. According to PSP Adyen, 3-D Secure in the USA leads to a decrease in the conversion of 45%.
• Restricted 3-D Secure. The 3-D Secure flow is used only for the 3-D Secure enabled cards as well as cards participated in Verified by Visa or Mastercard SecureCode programs.

Unfortunately, 3D Secure has a drawback: this additional step adds friction to the checkout flow and sometimes lead customers to abandon the purchase. Being of our mobile coverage they are not able to receive a code as a text message and it becomes a hard stopper for the purchasing process. Additionally, there are banks who force their cardholders to create and remember the passwords to complete 3D Secure verification. These layers of complexity lead to higher rates of shopping cart and checkout abandonment. 3D Secure 2 (3DS2) introduces “frictionless authentication” and improves the customer experience compared to 3D Secure 1. 3DS2 allows merchant systems and their payment service provider to send a richer set of data with the transaction, such as payment-specific data like the shipping address and contextual data, such as the device ID or transaction history. If bank decides this information is enough to trust that the real cardholder is making the purchase, the process becomes “frictionless” and no additional input is requested from the cardholder. If the data is not enough for the bank to trust and it needs further proof, the challenge flow is activated where the customer is asked to provide some additional input to authenticate the payment. Additionally, 3DS2 supports authenticating a payment through the banking app by just using their fingerprint or facial recognition. 3DS2 has not been implemented in many banks yet, but this year all leading issuers are working on the upgrade. The first version is not supposed to be sunset, so the merchants will have options. However, to support 3DS2 the merchant needs to do an upgrade on their side too. The efficiency of 3-D Secure from Badoo (2012-2013): In Russia, 3-D Secure was on by default from the very beginning. After Badoo turned it off, a percentage of successful payments increased by 20%. In Italy, after Badoo activated 3-D Secure, they were observing a decreas by 10-15%. In UK, 3-D Secure hasn’t changed much over there. The USA market was the most sensitive: the percentage of successful transactions was dropped significantly. 3-D Secure is not popular and for many customers it is a new and unexpected thing. Implementing and supporting 3DS & 3DS2 in the bank’s and merchant’s solutions are becoming important in the light of the new EU regulation, Payment Service Directive II. This regulation requires the banks to develop a range of technical guidance to flesh out the Directive. One of the measures is Secure Customer Authentication (SCA) which “is based on the use of two or more elements categorized as knowledge (something only the user knows, e.g. password or PIN) possession (something only the user possesses, e.g. the card or authentication code generating device) and inherence (something the user is, e.g. the use of a fingerprint or voice recognition)”.

8. Recurring Payments and Subscriptions

A subscription is basically an agreement that a customer makes in order to pay for something upfront that a customer going to receive regularly. Subscriptions, recurring payments, subscription models, recurring billing, recurring models – they are all one in the same thing. For recurring payments, you can process an authorization and capture by using information (token) that was collected from the payment service provider during the initial payment session and unique customer identifier (customer#). For example, you might want to charge a customer 20 USD every month to access the service you provide. The first transaction is similar to normal one (only a recurring flag is on). All subsequent transactions won’t require entering card details again. A customer recurring payment does not have to be the same amount each time. However, you must provide a clear explanation on the subscription policy before customer is subscribed for the service. If the amount varies based on usage, make it clear. It is important to make cancellations easy for the customer. Being busy, many customers naturally gravitate towards the easiest option to get their money back. For them, it may be much easier and faster to file a billing dispute rather than contact the merchant. Normally when customers enter the card details, they provide an expiration date for a payment card. For some processing companies, instead of sending the out-of-date expiration date, you can include a replacement expiration date. However, this functionality is not supported by all banks.

8.1. Handling Stored Credentials

Visa and MasterCard introduced the regulation that changed the way merchants and payment processors handle transactions and chargebacks made with the stored card details. One of the components of the regulation is Stored Payment Credentials Mandate (MasterCard), Merchant Initiated Transaction and Stored Credential Frameworks (VISA) which all dictate how merchants should handle and process payments made with credit card information saved on their servers, or “Stored payment credentials”. Merchant Initiated Transaction Framework divides transactions into two categories

• Merchant-initiated (MIT), such as automatic billing for subscription services
• Customer-initiated (CIT), such as paying for the order using a card stored in the my account area.

The following operations are available for merchant-initiated transactions:

• Incremental authorizations – to increase the authorized amount,
• Resubmission – when a decline is received due to insufficient funds when the product has already been delivered. Used by merchants to recover outstanding debt from cardholders,
• Reauthorization – when the completion or fulfillment of the order extends beyond the authorization validity limit set by Visa.
• Delayed charges – to process a supplemental account charge after original services have been rendered and respective payment has been processed.
• No Show – a transaction to charge the cardholder a penalty according to the merchant’s cancellation policy (hotels).

Merchants processing transactions in all regions are required to flag recurring transactions explicitly:

• As a Subscription for the transactions having a fixed or variable amount, which follows a fixed schedule.
• As a CardOnFile for the case when card details are stored on the merchant’s side (“saved cards”). Any subscription not following a fixed schedule is also considered as a card-on-file transaction.
• As a UnscheduledCardOnFile: A transaction that occurs on a non-fixed schedule and/or have variable amounts, such as automatic top-ups when a cardholder’s balance drops below a certain amount.

This information is relevant here because many payment integration APIs implement the MIT/SC Frameworks in their payment API.

9. Integration methods

9.1. Direct Integration (API)

According to this strategy, the website hosts the payment page and sends payment data to the payment service provider using the API. In the scenario, the merchant assumes the risk for securing the customers payment details, and must ensure their infrastructure and implementation are certified (PCI DSS) which carries additional cost and effort in a project. For using this option, the merchants have to be certified (PCI DSS). The code is not open for third parties, so this option is considered the least transparent and safe. However, for large good-standing brands, this is an option. You must use the Direct Integration model If you need full control over the transaction and you wish to manage your own payment page and collect and process payment details. The direct integration helps to increase conversion. The card can be linked to the account for faster checkout (one-click checkout). A form of direct integration is batch processing. It allows you to submit batches of operations, such as captures and refunds to the payment service provider without direct interaction with a payer.

9.2. Hosted Order Page (HOP)

Hosted Order Page (HOP) is the approach that requires a customer to be redirected to the payment page. The payment page is provided by the payment service provider. The user is redirected to this page for entering card details. Because the payment service provider is PCI DSS certified and highly focused on data security, this option is considered as safest. This externally hosted payment form can also be displayed in either a Lightbox modal dialog or an embedded iFrame. Such an approach are often called “Hosted Payment Form”. The modal dialog of full redirect is generally considered safer than iFrame-based option. Despite modern web browsers do not allow the parent page to access data within the child iFrame, this integration option has to be tested more thoroughly. There is a form of hosted order page concept, a button, such as “Pay Now” button from Paypal and “Pay with Amazon” from Amazon. Even with the hosted order pages some banks help to simplify the repeated purchases by using token-based authentication. This concept is also known as saved cards. However, the cards are not stored in the merchant’s system, but tokens. In this scenario, the initial payment is done using the hosted payment page, but further payment flow is greatly simplified. When a customer submits the form, the payment service provider binds this payment data to a unique customer identifier which comes from the merchant’s system and generate a unique token which goes in the merchant’s system. This token and last 4-6 digits of the card can be reliably stored in the merchant’s system. The merchant can then easily process payments or save customer details by including the token in the API requests. For next purchases, the client will be able to select a card from the list of their saved cards (only last digits are displayed) instead of entering full card details. CVC/CVV is still required for better security. Since the selected card is uniquely associated with the token received during the initial authorization, together with the CVC/CVV and unique customer identifier, the payment service becomes able to determine the card details reliably.

9.3. Silent Order Post (SOP)

Silent Order Post (SOP) is the approach in which a form hosted on the merchant side passes the sensitive payment data directly (and asynchronously, without a page reload / refresh in browser) to the payment service provider. This option is slightly improved version of direct integration. Instead of dealing with API calls, the system can send the form directly to the payment gateway. In this case, the part of the system responsible for sensitive data processing is open for inspection by third parties because the HTML code and Javascript code are open. Each option has its pros and cons and a choice should be based on the requirements and constraints specific to the project. The best practice approach is commonly using SOP, which offers the best user experience whilst still being PCI compliant.

10. Common pitfalls and challenges

10.1. Duplicate Payments

When a payment API supports idempotency, the payment integration module can make the same call repeatedly and the result will be the same. In other words, making multiple identical requests should be resulted in the same response as in the case of a single request. If the API doesn’t support idempotency, there is a dedicated parameter to help you keep track of your requests. This is a string that you include in the request. When you send a request with the same idempotency parameter value, the payment API will send back the current successful response. The complexity increases if you deal with more than one payment service provider implementing a fallback approach, and idempotency should be applied to a group of systems normally not integrated with each other.

10.2. Incorrect Currency Conversion

Many cross-border sellers lack the expertise in cross-border sales which often leads to lost sales and dissatisfied customers. Many consumers don’t know that banks may charge 3%-5% for currency conversion. Additionally, the banks may also charge a fee of around 3-5% for purchases made in a foreign currency, which won’t be revealed by the currency converter. As a result, customers are often shocked to discover their purchase ended up costing significantly more and they will be less likely to shop with you again. The process of currency conversion involves three currencies: transaction currency, billing currency, and payment card currency. If all currencies are the same, the conversion is not performed. However, if transaction currency and payment card currency are different, but then billing currency is the same as transaction currency, a issuer’s bank’ conversion fee will be applied. However, if transaction currency and payment card currency are different than the billing currency, you will get double conversion. Basically, there are the following fees:

• OIF – Optional Issue Fee (Visa)
• ISA – International Service Assessment (Visa)
• CBF – Cross Border Fee (Visa)

Different banks have very different terms on who pays what, the bank or a cardholder.

Payment system	Payment card currency	Billing currency	Transaction currency	Conversion rate
Visa	RUB	USD	USD	Issuer’s USD->RUB
Visa	RUB	USD	EUR	Issuer’s USD->EUR
Visa	RUB	USD	RUB	No conversion
Visa	USD	USD	USD	No conversion
Visa	RUB	USD	CHY	Visa’s USD->RUB + Issuer’s CHY->USD

The billing currency for Visa is USD, for Mastercard it is Euro or USD. There is a problem that the exchange rate might be applied with some delay from the purchase date. During this time the currency may change significantly. It may create a technical overdraft if you pay by debit card and you used all available funds from the account. On top of that, some payment aggregators, such as Paypal, convert the order price from the order currency (EUR in the example above from the diagram) into the cardholder’s currency (RUB in the example) with its own exchange rate. So, you can see the converted amount in the invoice that is positioned by them as an advantage and a customer-centric approach. Of course, when it comes to refunds, all currency conversion fees applied to the order are not returnable.

10.3. Incorrect Merchant Code

A Merchant Category Code (MCC) is a four-digit number selected by a merchant to classify its business by the types of goods or services it provides. This code affects a lot of things, from antifraud rules and restrictions to fees. For example, Badoo reported that their primary merchant code “7273 Dating and Escort Services” led to 50% successful payments rate. Changing it to “4814 — Telecoms” for one of the countries resulted in 30% increases. After changing the merchant code to “8641 — Social, Civic and Fraternity services” Badoo managed to increase the number of successful payments by an additional 10%. (the diagram is from Badoo)

10.4. Expired Authorization

This scenario is explained in detail in the “Payment Clearing and Settlement” section, “Late Capture”.

10.5. Expired Web Session

When a customer selects payment gateway, and it redirects them to the payment page, and a customer spends too much time at the payment page (more than the bank thinks normal) or at the 3-D Secure page, there is a risk that the flow won’t be continued because of session of the parent system is expired. The following figure explains this issue: There are two problems depicted:

• Payment page session is expired when 3-D Secure page takes too much time
• Merchant’s website session is expired by the time the customer is come back from payment session provider’s flow

10.6. Failed Notification Webhooks

The notifications are webhooks informing a merchant of important events related to the transactions, for example, when the order is paid. They are crucial for a successful integration with the payment system. However, the webhook URL might not be reachable for the payment system 24/7 because of planned and non-planned outages. Different PSPs have different retry policies. For example, Stripe attempts to deliver the webhooks for up to three days with an exponential back off. Stripe webhooks cannot be manually retried after this time, though you can query for the event to reconcile your data with any missed event. This mechanism is often ignored in the custom implementations in the belief that the probability of having lost events is negligible. In fact, it is a very common case for large retailers.

10.7. Abandoned Carts (because of no payment)

It is also common that a customer being redirected to the payment page doesn’t come back. It can happen because of issues on the payment service provider’s side or during the 3-D Secure flow. These systems are responsible for redirecting the customer back to the merchant’s website, but in fact many of them are configured to do it only for standard scenarios. If it happens, the customer may decide to come back to the merchant’s website “manually”, and retry. There are two options what the customer will see:

1. Order has not been placed; The shopping cart has not been emptied. The shopping cart still contains all the products ordered.
2. Order has been placed but marked as “unpaid”; The shopping cart has been emptied. There is a link to the order payment page from the My Orders page. The system sends an email saying that the order is placed, but has not been paid, with a link.
3. Order has not been placed. The shopping cart has been emptied. The customer needs to add a product(s) to the shopping cart again and proceed with the checkout again.

The recommended option is #2.

10.8. Split/Partial Payments

This option is used in many customer scenarios, especially in the large markets with well-developed payment system industry. For example, the customer wants to use a Visa gift card or e-Wallets (such as Webmoney, AliPay, Qiwi) and a credit card for paying for the product which price is higher than a gift card value. Also, it is relevant for household appliances category when a customer decides to pay mostly in cash (a “cash-on-delivery” model), but a store wants to get an upfront payment to reduce the risk of no-show. And finally, brick-and-mortar stores generally allow to pay with multiple credit cards or mixture of pay-ins, why don’t use it for online point of sale? Most e-retailers do not allow for split payments because of technical and operational complexity of the order management processes.. There is no universal recommendation because every detail matters. For partial payments, it is crucial to take into account every twist and turn of the customer journey. You need to account for scenarios such as fraudulent activities and whole or partial returns and refunds.

10.9. Reasons why the payment can be declined

• Not enough funds available. This decline status is set by the issuing bank.
• Card-related:
  • Prepaid cards and gift cards may not be accepted.
  • Incorrect credit card details (number, expiration date, CVV/CVC). This decline status is set by the issuing bank or acquiring bank.
  • Checksum is not correct
  • Account number doesn’t exist or blocked or inactive
  • Bank ID is invalid
  • The requested operations or transaction types are not permitted (such as online purchases or entertainment for the business credit cards)

• Bank and processor related:
  • Technical difficulties or maintenance in acquiring bank, issuing bank or payment processor.
  • International transactions are not allowed for/by the acquiring bank (to reduce fraud)
• Merchant-related:
  • The processing limit on the merchant account has been reached
  • International transactions are not allowed for/by the merchant (to reduce fraud)
  • 3-D Secure is not enabled for the card, but required by the merchant (to reduce fraud)
• Fraud filters. Combines the following components to take a decision
  • Address verification service: returns data different from expected?
  • Card velocity: threshold number of approved authorization or sales occurred within pre-set time period
  • Prior fraud advice: a merchant receives a fraud advice?
  • IP geolocation: the location of the customer is different from expected?

11. Payments in SAP Commerce

11.1. What’s Coming Out of the Box

SAP Commerce Cloud can be integrated with any payment gateway or payment strategy. For the vast majority of payment service providers, the-out-of-the-box payment module can be used as a skeleton for the specific PSP. Choosing a payment service provider is often a consequence of the merchant’s commercial decision regarding the acquirers they choose to use, driven by where their customers are. Many of the world leading PSPs are partners of SAP and have integrations available on the SAP App Center. Payment integration is generally less complex in B2B scenarios because companies generally pay on account.

11.2. Payment Process

Below is an example of the payment process available out of the box (the Payment Service Provider implementation is mocked). When a customer indicates they are ready to checkout, the customer is redirected to a payment page. This page can be hosted by merchant or payment provider. In case of merchant payment page, according to the HOP approach, the page contains a particular IFrame. The content of this iFrame is derived by a call out to the payment service provider servers. The customer inputs the payment information into the iFrame (merchant’s payment page) or payment page provided by the payment provider, and submit the payment. The payment gateway validates the requests and process the payment. Once a payment is processed, the payment information can be stored in a customer profile on the payment service provider servers. When the transaction is completed, the payment service provider returns the payment information to the merchant. The funds are just blocked at this phase. Depending on the merchant’s order fulfillment process, they can be settled immediately or when a particular event occurs, such as “order ready for delivery” or “order is sourced”.

11.3. Payment data model in SAP Commerce

The Cart or Order may have a Payment Transaction which has at least one Payment TransactionEntry. One order can contain multiple paymentinfo objects which makes it possible to store information about multiple payments per order, each with a different billing address.

11.4. SAP Commerce Payment Module Architecture

SAP Commerce Payment module is designed to support only credit and debit cards. SAP Commerce Cloud is shipped with the mocked implementation of the Payment Service. Example of the custom implementation of the Capture command for Adyen is here. There’s a lot of choice in the payment gateway market, and customers generally bring their choice of payment gateway to a project. Some specific implementations are not based on the out-of-the-box skeleton. The card number validation is implemented out of the box (cardValidator.luhnCheck). Until version 5.3, hybris (the former name of SAP Commerce) had been shipping with Cybersource extension.

12. What is next? Web Payments Standard from W3C is coming

The W3C has been developing new standards to help make online payments much easier and safer. The standard dramatically simplifies checkout flow for the customers. With just a few taps, the consumers will be able to make a payment instead of typing small characters many times on a virtual keyboard. The standard also makes it easy for merchants to implement with a variety of payment options already filtered for the customer. Web Payments comprises multiple web standards:

• Payment Request API which provides a consistent checkout flow while reducing the need for users to enter their shipping and payment information on every checkout.
• Payment Handler API which opens up the ecosystem to payment providers by allowing their web-based payment applications to act as payment methods on merchant websites.
• Payment Method Identifiers which defines how strings (basic-card, https://google.com/pay, etc.) can be used to identify a payment method. Along with standardized payment method identifiers, it allows anyone to define their own payment method with URL-based payment method identifiers.
• Payment Method Manifest which defines the machine-readable manifest file, known as a payment method manifest, describing how a payment method participates in the payment ecosystem, and how such files are to be used.

(the example is taken from the Ruslan Solomakhin’s repository. Ruslan is a Chromium Developer at Google)> Payment Request API is currently supported by Chrome for Android, Chrome on desktop (Mac, Windows, Linux) and Microsoft Edge Currently, Google Pay and Microsoft Pay are designed to work with Payment Request API. Not all payment service providers support Google Pay, see the list. As for Chrome support, Google already implemented PR API on Android devices, with iPhones being late to the party. The API is designed to handle virtually any kind of payment methods including bank transfers, cryptocurrencies, e-money, points, etc The customer selects the payment method and approves the payment. Then the browser generates the JSON response which contains all of the information required to initiate the payment via a payment service provider: (the example is taken from the Ruslan Solomakhin’s repository. Ruslan is a Chromium Developer at Google)> Currently, the standard is not fully supported by browsers and devices yet. More information about Web Payments:

• https://w3c.github.io/payment-handler/
• https://developers.google.com/web/fundamentals/payments/

Supporting Web Payments Standard is on roadmap of SAP Commerce Spartacus.