Overview (GLOBAL)

When using our Gateway and Fiserv as the 3-D Secure provider, the authentication is performed in-line with the existing transaction flow. The process starts by performing a typical authorization or sale request with a desire to perform 3-D Secure authentication in the request.

The authorization is then placed into a WAITING status until the authentication process is completed. During authentication, the merchant may be required to update the original transaction request one or more times in order to move the process flow forward.

At the end of the authentication process, the original transaction is updated with the authentication results and the authorization is completed.

The sequence diagrams below map to the steps in the text that follows. The first diagram is for the frictionless flow. This means the issuer does not require the cardholder to authenticate.

The next diagram shows the flow when your customer has to authenticate, which means their issuer has requested they provide additional authentication details.

Use the Card Verification service to check a card is available for charging before a customer uses it to pay.

A card verification lookup will perform a zero value authorization against the card to ensure it is not fraudulent, blacklisted, expired or blocked. Essentially it lets you check whether the card and account are in good standing and available to make payment.

For regions where strong customer authentication isn't required, you can use a dedicated endpoint from our RESTful payment API. For all other regions use standard primary transaction with zero amount (sale or preauthorisation) in combination with 3DS.

The Gateway allows to send individual information along with the payment request.

Independent of the chosen submission component, the custom parameters are sent as key value pairs to the Gateway.

For some solutions such as Fraud Detect these custom parameters will be used for further information.

When a transaction is made from an account that is in a different native currency than the merchant currency, there are two ways that currency conversion can happen:

• At the time the transaction is cleared, this is the standard way and relies on no up-front configuration
• At the time the transaction is authorised, which is done using a process called DCC (Dynamic Currency Conversion)

Our APIs offer the ability to achieve both, but for context, why would someone want to use DCC?

Pros

• It offers visibility to the consumer at time of sale in their native currency for improved transparency
• The exchange rate is locked in at the time of transaction

Cons

• The rate is usually less favorable, resulting in a higher transaction cost to the consumer

📘

Please note, that for compliance reasons Currency Conversion can only be offered on transactions that take place in full at that time (e.g. Sale, Refund) and not on any delayed settlement (e.g. recurring) due to the fluctuation of the rate of exchange.

The tokens are surrogate values that replace Primary Account Number (PAN) stored electronically throughout the payments system. This single token allows you to reference previously used card details for:

• Faster re-use of existing payment details
• Removing the need to store the details in your systems, reducing PCI requirements

The only thing you need to store on your system is the token itself, a unique string, and map it to your customer's account details.

JavaScript

Tokenization with JavaScript allows you to use the advantages of an API interaction (server-to-server) and at the same time benefit from a solution that keeps sensitive card details away from your own systems, alleviating compliance with the PCI Data Security Standard.

In a first step, you tokenize card details that you can then use for later payment transactions via API requests that include the token instead of card details.

This option gives you maximum flexibility for the look and feel of the entry form in your webshop while a JavaScript library encrypts the sensitive information before it hits your servers. This can be an alternative to a Direct Post integration if you are only looking for tokenization and plan to handle all subsequent steps with our APIs.

The JavaScript for tokenization works across multiple Fiserv solutions including our gateway.
Please see integration documentation here: Payment.js

The Fraud Detect process flow can be described as follows:

1. You send a payment transaction request to our Gateway.
2. The Gateway submits the transaction details to Fraud Detect.
3. The Gateway receives the response from Fraud Detect incl. a fraud score (between 1-1000)
4. Next step depends on the result of fraud check:
   1. If approval is received, then the Gateway routes the transaction to the authorisation system
   2. If decline is received or fraud score is below value configured on store level (default 500), then the Gateway will forward this result to you

Merchant-Initiated Transactions (MIT) are payments initiated by the merchant without the interaction of the payer. They are characterized by a lack of involvement of the payer in triggering each individual payment.
Such payments require that:

SCA is applied to the first transaction or action mandating the Merchant to initiate payment(s) and
There is an agreement between the payer and the merchant for the provision of products or services and potential costs associated with these.
Such payments can happen in the following cases:

• Recurring Payments for fixed or variable amounts
• Merchant funded installments
• The final amount is higher than the amount used at authentication time.

This can happen when additional charges are added to the initially agreed amount such as, a minibar in a hotel or fines with a rented car.

In case you would prefer to register your customer and store his credit card credentials on file, you are obliged to obtain cardholder’s consent by using Strong Customer Authentication (SCA) in your transaction request.
In order to achieve that, your cardholders must authenticate themselves during transaction processing, once the cardholder is still in session. PSD2 and scheme rules demand a 3-D Secure challenge flow to be performed in such case.

All mentioned above needs to be indicated to the Gateway, so that proper transaction flagging is applied in the authorization message.

Mastercard Money Send is a payment service provided by Mastercard that allows individuals to send money to friends, family, or businesses securely and conveniently. It enables users to transfer funds electronically, making it easier to send and receive money across different locations. The service is often utilized for person-to-person payments but there are many more business scenarios.

Please note that you can only use this feature if your account is connected to specific authorization systems.
For more details please contact you client representative.

Mastercard mandates the initiator of the payment to provide specific details in each transaction. Please refer to the individual integration guides for more information.

Network tokens are surrogate values that replace Primary Account Number (PAN) stored electronically throughout the payments system. Network Tokens can be used to conduct payment transactions securely and can provide improved protection against fraud, because network tokens can require cryptogram validation or be limited to use in a specific domain or circumstance, such as token requestor, device or channel.
The purpose of this article is to describe the process how to generate and use the network tokens in the Gateway.

Initial Setup and Conditions
In order to utilise network tokens, it is necessary to change your account setup respectively. Please contact your boarding team or customer support team to manage the setup for you.

In case you are located in India, due to compliance requirements you need to obtain and capture customer’s consent and perform Strong Customer Authentication (SCA) before customer’s credit card is tokenized. You can authenticate your customer by using a 3-D Secure request followed by successful authorization which thereby provides you with the permission to request a network token. Please note, that you should not store card number at your end and generate the token instead.

Payment facilitators (PFAC) take the role of a service provider, and are merchants registered by an acquirer to facilitate transactions on behalf of sub-merchants. The provider of the goods/services becomes the sub-merchant instead of the merchant. When the cardholder makes a purchase, the sub-merchant routes the transaction data to the payment facilitator. The payment facilitator incorporates all necessary transaction and merchant identification data and sends this to the acquirer.

There are the two most commonly used PFAC models - Single-MID and Multi-MID model.

Single-MID model also known as Aggregator does not provide a separate merchant ID (MID) to their sub-merchants, they use aggregator’s own MID, simplifying the process for businesses that handle very low volumes of transactions.
Multi-MID model provides MID for each of the sub-merchants, that sign on under them. This model works great for medium sized businesses who don’t want to deal with the hassle involved in the traditional model.

The way how PFAC transactions are processed and flagged in the authorization message depends mainly on your boarding requirement, if you wish to get all your sub-merchants boarded in the Gateway or you would rather prefer to avoid boarding all your sub-merchants and initiate all transactions from your master-store (PFAC merchant).

Payment URL is a functionality that allows you to provide a link to your customers (e.g. in an email invoice, WhatsApp message, SMS, etc. which then takes the customer to a Fiserv-hosted page to securely make the payment with their preferred payment method, whenever convenient for them.

This is especially useful in scenarios where goods get paid after delivery, where no goods get shipped at all (e.g. final payment for trips that have been booked months ago) or for the payment of monthly bills.

You can also implement this functionality for unsuccessful purchases where the original payment transaction has been declined so that you can proactively give your customer a second chance to make their purchase.

Our product provides:

• The capability to request a Payment URL (link) for a specific amount through API
• A hosted payment page where the customer can select the preferred payment method (based on the payment methods that are activated for your account) and make the payment
• A hosted result page that tells the customer if the payment was successful or not, including a Retry button where the customer can chose a different payment method in case the transaction was not successful

There are two different solutions in place - one is linked to the Hosted Payment Page (Connect) and one which is linked to the new Checkout solution. Below you can find an overview about the connections being in place:

In cases where a one-off payment is not sufficient, such as a recurring monthly subscription or a payment split across a number of months, our recurring payment features can be used.