A note from 2026: This article was published in 2019. Since then, 3-D Secure 2 and PSD2/SCA have become standard in many regions, SAP Spartacus has been renamed SAP Composable Storefront, SAP App Center is now SAP Store, and SAP Commerce Accelerator payment examples are considered legacy in new composable implementations.

Rauf Aliev portrait

Payments are 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 to shed some light on payment integration and related complexities. It provides brief context on the payment system and the key regulatory principles and best practices you need to know before designing and implementing the payment module.

We also cover the often-forgotten edge cases you need to handle for large e-commerce solutions. You will learn what to expect and how to address 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 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 developed in detail, but the core concepts have remained largely the same.

My co-author, friend, and colleague, Aleksey Kryuchkov, Software Engineer at EPAM, helped explain how card payments should be handled properly based on his work experience with a large retail company in Russia, and what collisions and edge cases with card payments a large online store can face. Before joining EPAM, Aleksey had worked for more than eight years as Head of Development at 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 earlier).

Table of Contents

1. Payment Processing in a Nutshell

1.1. Parties

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

How these parties operate with one another is shown below.

Parties involved in card payment processing

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. Payment aggregators such as Google Checkout and Amazon Payments differ in their 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. The first six digits stand for the issuing bank ID, the next nine digits are the 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) IIN/BIN (bank ID) IIN/BIN (bank ID) IIN/BIN (bank ID) IIN/BIN (bank ID) PAN, customer account number (1-12 digits) PAN, customer account number (1-12 digits) PAN, customer account number (1-12 digits) PAN, customer account number (1-12 digits) PAN, customer account number (1-12 digits) PAN, customer account number (1-12 digits) PAN, customer account number (1-12 digits) PAN, customer account number (1-12 digits) PAN, customer account number (1-12 digits) Check digit
From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits From 8 to 19 digits 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:

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:

Key components of payment processing

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, acquiring bank, payment card network, and issuing bank are involved. This model applies to Visa/MasterCard transactions. For other networks, such as American Express and Discover, the model is simpler: the network and the bank are the same entity. The process for such cases is known as the “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 cardholder’s validity, ability to pay, 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. The customer submits the card details to the payment service provider (via the 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 the 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.

Card authorization process

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

Some banks support zero-amount authorizations. This operation shows whether a payment card account is valid and whether the card is lost or stolen. For the same purpose, some services authorize the smallest amount ($1) and release 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 timeframe is 7 days for normal transactions, and 24 hours for recurring transactions and some kinds of businesses (restaurants, taxis, and some others). For travel-related business models, the timeframes are extended (31 days) to allow more flexibility.

For Mastercard, the default expiration timeframe is 30 days for normal transactions and 7 days for recurring transactions.

Issuing banks can extend these timeframes at their own discretion.

In SAP Commerce Cloud, the default payment interface doesn’t have any functionality to keep the expiration timeframe 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.

Payment clearing and settlement process

4.1. Late Capture

A capture does not happen in real time. All 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 into your merchant bank account.

The second reason for the delay is make-to-order and pre-order products, when merchants can take advantage of the gap between when funds are held in the cardholder’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 approach, using 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.

Late capture and expired authorization timeline

The issuing bank and payment service provider may have different expiration times for authorization transactions. When the transaction expires in the issuing bank, the payment service processor and 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 consists of three components:

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 situations when a customer cancels the order before the order amount is settled, or when the availability check shows 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 might be problematic for the merchant because the issuer’s bank doesn’t notify the merchant or their processing service provider about the change. However, authorization reversal initiated by a customer is preferable to 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 released quickly. 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 the standard Accelerator order management process (cancelOrderAction). By default, this implementation is mocked. SAP Commerce also provides the 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 starts. As a result, a decision is made to return funds for the disputed charge — this is a chargeback.

Merchant 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 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 Sales Draft Requests. If there is no reply within a certain timeframe, or the proof is poor, the bank issues the chargeback, which is covered automatically from the merchant’s account or, when there are no funds, by the merchant’s bank. 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 merchants based on chargeback count and chargeback-to-sales ratio. For example, in Visa, monthly 500 chargebacks and a 2% ratio will lead to categorization 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, it is better to 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 are 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 the merchant to return the whole or part of the transaction amount to the customer.

Most merchants allow customers to receive a refund back to the credit card they used for the original purchase. If the original card has 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, just as handling returns is not free. However, 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 disputed 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, is 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-established public policy that 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 a double refund situation.

6.3.1. Partial Refunds

Partial refunds are used for situations in which a customer orders multiple products and decides to return only some items.

In our experience, 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 easy for the end user to understand, but it also poses some limitations that should be taken into account during development. If there is a promotion applied to the order, and the promotion has been changed or disabled since the order was 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 had bought only the case from the very beginning, the delivery would not be free because of the free delivery threshold. After the phone is excluded from the order, the delivery remains free. So this causes additional costs for the merchant to incur.

6.3.2. Refunds for Digital Products

Refunds can be requested for many reasons. The downloaded software product may not function as expected on the customer side or may not be compatible with the user’s setup. The customer may just change their mind and decide that the product is no longer needed. The refund request can be filed because of poor quality. In all cases, the product has already been delivered and cannot be returned 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 the 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 to lose 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 that enables customers 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 sections. Normally, merchants are liable for fraudulent transactions. With 3-D Secure in play, responsibility for fraud is shifted from the merchant to 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:

3-D Secure flow diagram

(The diagram is from Wikipedia with some amendments.)

A very simplified 3-D Secure process is as follows (numbered steps are depicted in 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 results in a Verification Response.
  4. If verification is not possible, the request results in “Cardholder not Enrolled” or “Authentication not available”, and the Customer is redirected to the standard flow (not 3-D Secure). If verification is possible, Access Control Server sends the issuer’s 3-D Secure form (URL) in the response.
  5. Directory Server sends the Verification Response (with the URL of 3DS or without it) from the previous step to the 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 3-D Secure page by entering a code from a text message or accepting the request in the bank app. The 3-D Secure authentication mechanisms vary in different banks. For local payments, text messages or push notifications are used. The customer receives a one-time password (code) in the message.
  8. The result of this authentication attempt 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 3-D 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 various add-ons, such as:

Unfortunately, 3-D Secure has a drawback: this additional step adds friction to the checkout flow and sometimes leads customers to abandon the purchase. If they are out of 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 that force their cardholders to create and remember passwords to complete 3-D Secure verification. These layers of complexity lead to higher rates of shopping cart and checkout abandonment.

3-D Secure 2 (3DS2) introduces “frictionless authentication” and improves the customer experience compared to 3-D 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 the 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 a 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 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):

Badoo statistics on 3-D Secure efficiency

In Russia, 3-D Secure was on by default from the very beginning. After Badoo turned it off, the percentage of successful payments increased by 20%. In Italy, after Badoo activated 3-D Secure, they observed a decrease of 10–15%. In the UK, 3-D Secure didn’t change much. The USA market was the most sensitive: the percentage of successful transactions dropped significantly. 3-D Secure is not popular and, for many customers, it is a new and unexpected thing.

Implementing and supporting 3DS and 3DS2 in bank and merchant solutions is becoming important in light of the new EU regulation, Payment Service Directive II. This regulation requires 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 upfront for something they are going to receive regularly. Subscriptions, recurring payments, subscription models, recurring billing, recurring models — they are all one and 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 a 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 a normal one (only a recurring flag is on). All subsequent transactions won’t require entering card details again.

Recurring payments overview

A customer’s recurring payment does not have to be the same amount each time. However, you must provide a clear explanation of the subscription policy before the customer subscribes to the service. If the amount varies based on usage, make it clear.

Recurring payment schedule and amount variation

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 than to contact the merchant.

Normally, when customers enter card details, they provide an expiration date for the 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 regulations that changed the way merchants and payment processors handle transactions and chargebacks made with stored card details.

One component of the regulation is the Stored Payment Credentials Mandate (MasterCard), and the 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”.

The Merchant Initiated Transaction Framework divides transactions into two categories:

The following operations are available for merchant-initiated transactions:

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

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 this scenario, the merchant assumes the risk of securing the customer’s payment details and must ensure their infrastructure and implementation are certified (PCI DSS), which carries additional cost and effort in a project. To use this option, merchants have to be certified (PCI DSS). The code is not open to third parties, so this option is considered the least transparent and safe. However, for large brands in good standing, this is an option. You must use the Direct Integration model if you need full control over the transaction and wish to manage your own payment page and collect and process payment details.

Direct integration helps to increase conversion. The card can be linked to the account for faster checkout (one-click checkout).

Direct payment integration model

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 to enter card details. Because the payment service provider is PCI DSS certified and highly focused on data security, this option is considered the safest.

This externally hosted payment form can also be displayed in either a Lightbox modal dialog or an embedded iFrame. Such an approach is often called a “Hosted Payment Form”. The modal dialog or full redirect is generally considered safer than the iFrame-based option. Although 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 the hosted order page concept: a button, such as the “Pay Now” button from PayPal and “Pay with Amazon” from Amazon.

Even with hosted order pages, some banks help simplify repeated purchases by using token-based authentication. This concept is also known as saved cards. However, cards are not stored in the merchant’s system; tokens are. In this scenario, the initial payment is made using the hosted payment page, but the 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 that comes from the merchant’s system and generates a unique token that goes into the merchant’s system. This token and the 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 future purchases, the client will be able to select a card from the list of their saved cards (only the 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 can reliably determine the card details.

Hosted order page integration model

9.3. Silent Order Post (SOP)

Silent Order Post (SOP) is the approach in which a form hosted on the merchant side passes sensitive payment data directly and asynchronously, without a page reload/refresh in the browser, to the payment service provider. This option is a 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.

Silent Order Post integration model

Each option has its pros and cons, and the 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 while 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 result 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.

Idempotency and duplicate payment prevention

The complexity increases if you deal with more than one payment service provider while implementing a fallback approach, and idempotency should be applied to a group of systems that are normally not integrated with each other.

10.2. Incorrect Currency Conversion

Many cross-border sellers lack 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, 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 that 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, conversion is not performed. However, if the transaction currency and payment card currency are different, but the billing currency is the same as the transaction currency, an issuer bank’s conversion fee will be applied. However, if the transaction currency and payment card currency are different from the billing currency, you will get double conversion.

Currency conversion scenarios for card payments

Basically, there are the following fees:

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 use 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 their own exchange rate. So, you can see the converted amount in the invoice, which 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 a 50% successful payment rate. Changing it to “4814 — Telecoms” for one of the countries resulted in a 30% increase. 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%.

Badoo merchant code impact on payment success rate

(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 a payment gateway, and it redirects them to the payment page, and the customer spends too much time on the payment page (more than the bank considers normal) or on the 3-D Secure page, there is a risk that the flow won’t be continued because the parent system’s session has expired. The following figure explains this issue:

Expired web session during payment flow

There are two problems depicted:

10.6. Failed Notification Webhooks

Notifications are webhooks informing a merchant of important events related to 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 unplanned outages.

Different PSPs have different retry policies. For example, Stripe attempts to deliver webhooks for up to three days with exponential backoff. 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 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 who is 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 three options for what the customer will see:

  1. The order has not been placed; the shopping cart has not been emptied. The shopping cart still contains all the products ordered.
  2. The 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 has been placed, but has not been paid, with a link.
  3. The order has not been placed. The shopping cart has been emptied. The customer needs to add the 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 large markets with well-developed payment system industries. For example, the customer wants to use a Visa gift card or e-wallets (such as WebMoney, AliPay, or Qiwi) and a credit card to pay for a product whose price is higher than the gift card value. It is also relevant for the 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 customers to pay with multiple credit cards or a mixture of pay-ins, so why not use it for an online point of sale?

Most e-retailers do not allow split payments because of the 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

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’s 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 the merchant or payment provider. In the case of a 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 submits the payment.

The payment gateway validates the request and processes 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”.

SAP Commerce out-of-the-box payment process

11.3. Payment Data Model in SAP Commerce

SAP Commerce payment data model

The Cart or Order may have a Payment Transaction that 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

The SAP Commerce Payment module is designed to support only credit and debit cards.

SAP Commerce payment module architecture

SAP Commerce Cloud is shipped with the mocked implementation of the Payment Service. An 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.

Card number validation is implemented out of the box (cardValidator.luhnCheck).

Until version 5.3, hybris (the former name of SAP Commerce) had been shipped with the 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 the checkout flow for customers. With just a few taps, 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 a variety of payment options already filtered for the customer.

Web Payments comprises multiple web standards:

Payment Request API checkout example

(The example is taken from 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 method, 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:

JSON response generated by Payment Request API

(The example is taken from 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:

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

Hybrismart.com // Rauf Aliev, Solution Architect