Payments: A look Inside the Black Box
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.
AuthorsMy 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
- 2. Credit Card Transaction Process
- 3. Payment Authorization
- 4. Payment Clearing and Settlement (Charge)
- 5. Fees that Affect Rates
- 6. Payment reversals
- 7. 3-D Secure and Liability Shift
- 8. Recurring Payments and Subscriptions
- 9. Integration methods
- 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
- 12. What is next? Web Payments Standard from W3C is coming
1. Payment Processing in the nutshell
1.1. PartiesThe 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.
1.2. Anatomy of a Credit Card NumberThe 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.
|IIN/BIN (bank ID)
|PAN, customer account number (1-12 digits)
|From 8 to 19 digits
- 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
1.3. Payment ProcessingThe 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 ProcessThe transaction process can be broken down into two stages:
- Authentication and Authorization. In the authorization stage, the merchant obtains approval for payment from the issuing bank.
- Clearing and Settlement. In this stage, the transaction is posted to both the cardholder’s credit card statement and the merchant’s statement.
3. Payment AuthorizationAuthorization 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 ProcessIn the authentication stage, the issuer verifies the validity of the customer’s credit card.
- Customer submits the card details to the payment service provider (via payment form)
- Credit card details are sent to the acquiring bank and credit card network for approval.
- The credit card network clears the payment and requests payment authorization from the issuing bank.
- 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.
- The acquiring bank delivers the result to the merchant.
- The issuing bank also places a hold in the amount of the purchase on the cardholder’s account.
- 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).
3.2. Zero Amount AuthorizationsSome 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 LimitThere 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.
- At the end of each business day, the approved authorizations are sent in a batch to the acquiring bank or processor.
- The acquiring processor forwards them to the credit card network for settlement.
- The credit card network routes each approved transaction to the appropriate issuing bank.
- The acquiring bank credits the merchant’s account for cardholder purchases
- The issuing bank posts the transaction to the cardholder’s account.
4.1. Late CaptureA 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 RatesDiscount 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 ReversalThe 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 ChargebacksCustomers 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. RefundsA 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 RefundsPartial 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 ProductsRefunds 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 CurrencyThis 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 MerchantEach 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 Shift3-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 Customer enters their card information (card number, expiration date, CVV/CVC etc.)
- 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).
- If enrolled, Directory Server sends a Verification Request (VEReq) to the issuer’s Access Control Server. This request is resulted in Verification Response.
- 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.
- 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).
- The merchant plugin redirects the cardholder to the URL received in the response.
- 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.
- The result of this authentication attempts is recorded into Authentication History Server. These records can be used later for dispute resolutions.
- Access Control Server digitally signs the Authentication Response and sends it to the merchant plugin.
- 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.
- The Acquiring Bank authorizes the transaction by contacting the credit card network and issuing bank
- The Payment Service Provider redirects the customer back to the merchant’s website, to a success or error page.
- 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.
8. Recurring Payments and SubscriptionsA 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 CredentialsVisa 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.
- 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).
- 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.
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.
10. Common pitfalls and challenges
10.1. Duplicate PaymentsWhen 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 ConversionMany 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)
|Payment card currency
|Visa’s USD->RUB + Issuer’s CHY->USD
10.3. Incorrect Merchant CodeA 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 AuthorizationThis scenario is explained in detail in the “Payment Clearing and Settlement” section, “Late Capture”.
10.5. Expired Web SessionWhen 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 WebhooksThe 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:
- Order has not been placed; The shopping cart has not been emptied. The shopping cart still contains all the products ordered.
- 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.
- 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.
10.8. Split/Partial PaymentsThis 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.
- 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)
- 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 BoxSAP 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 ProcessBelow 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 CommerceThe 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 ArchitectureSAP 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 comingThe 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.