Overview (GLOBAL)

In the card payments industry, Account Name Inquiry (ANI) is a scheme service that allows a merchant, wallet provider, payment facilitator, or payment service provider to verify whether the name entered by a customer matches the name on file with the card issuer before processing a transaction.

3-D Secure authentication runs inside the normal Gateway transaction flow when Fiserv is used as the 3-D Secure provider. The merchant starts with a normal authorization or sale request and indicates that 3-D Secure authentication should be performed.

The authorization remains in WAITING status until authentication is complete. During that time, the original transaction may need to be updated one or more times to move the flow forward.

When authentication finishes, the original transaction is updated with the authentication result and the authorization is completed.

The frictionless flow applies when the issuer does not require the cardholder to authenticate.

The challenge flow applies when the issuer requires the cardholder to provide additional authentication details.

Apple Pay provides secure checkout in an app or on a website.

The buyer taps the Apple Pay button, selects the payment card, and confirms the transaction with Touch ID or the available device authentication method.

The merchant app creates a transaction ID through the merchant server and receives the encrypted Apple Pay payment payload from PassKit. That payload contains the tokenized card data, cryptogram, and transaction details.

The encrypted payload is sent to the processor API through the Apple Pay SDK. The processor API decrypts and processes it, then returns an approval or decline to the merchant app.

Google Pay is Google's digital payment service that lets users make payments with a smartphone, smartwatch, or web browser instead of entering card details manually or using a physical card.

Card Verification checks whether a card is available before a customer uses it for payment.

The lookup performs a zero-value authorization to validate that the card is not fraudulent, blacklisted, expired, or blocked. It confirms that the account is in good standing and can be used for payment.

Where strong customer authentication is not required, a dedicated REST endpoint can be used. In other regions, use a normal primary transaction with zero amount, such as sale or preauthorization, together with 3DS.

The Gateway can receive additional merchant-defined information together with the payment request.

Custom parameters are submitted as key-value pairs, independent of the submission component used.

Some solutions, for example Fraud Detect, can use those parameters as additional transaction context.

When the cardholder account currency differs from the merchant currency, currency conversion can happen in two ways.

• At clearing time, which is the standard approach and does not need upfront configuration.
• At authorization time, using Dynamic Currency Conversion.

Pros

• The consumer can see the amount in their native currency at the time of sale.
• The exchange rate is fixed at transaction time.

Cons

• The rate is usually less favorable, which can increase the transaction cost for the consumer.

Data Vault tokens are surrogate values that replace the stored Primary Account Number. They let merchants reuse card details without storing the sensitive card data themselves.

• Existing payment details can be reused faster.
• PCI exposure is reduced because the merchant stores only the token.

The token is a unique value that can be mapped to the customer's account in the merchant system.

JavaScript

JavaScript tokenization supports an API-style integration while keeping sensitive card details away from merchant servers. First the card is tokenized, then later transactions can use the token instead of the card details.

This gives merchants flexibility over the look and feel of the card entry form while a JavaScript library encrypts the sensitive data before it reaches the merchant environment.

Deferred authorization captures the card and transaction details first, while issuer authorization is requested later instead of during the live customer interaction.

Typical use cases include:

• Connectivity issues, for example when a terminal is offline or has unstable network access.
• High-throughput environments where the merchant wants to keep the checkout line moving and complete authorization afterwards.

The Fraud Detect flow is:

1. The merchant sends a payment transaction request to the Gateway.
2. The Gateway sends transaction details to Fraud Detect.
3. Fraud Detect returns a result and a fraud score between 1 and 1000.
4. If the result is approved, the Gateway routes the transaction to authorization.
5. If the result is declined, or the score is below the configured store threshold, the Gateway returns that result to the merchant.

Merchant-Initiated Transactions are payments initiated by the merchant without payer interaction for each individual payment.

These payments require that SCA is applied to the first transaction or action that authorizes future merchant-initiated payments, and that an agreement exists between payer and merchant for the related products, services, and costs.

Examples include:

• Recurring payments for fixed or variable amounts.
• Merchant-funded installments.
• A final amount higher than the amount used during authentication.

This can happen when additional charges are added later, such as hotel minibar charges or rental car fines.

The Gateway must receive the correct indicators so the authorization message can be flagged properly.

Network tokens are surrogate values that replace the Primary Account Number in payment processing. They can improve security because usage can be limited by token requestor, device, channel, or another domain-specific condition.

Initial setup and conditions

Using network tokens requires account setup changes. The boarding or customer support team must manage the required configuration.

For India, compliance requires customer consent and Strong Customer Authentication before the card is tokenized. The customer can be authenticated through 3-D Secure followed by successful authorization, after which the network token can be requested.

Payment facilitators act as service providers and are registered by an acquirer to facilitate transactions for sub-merchants. In this model, the provider of goods or services becomes the sub-merchant.

When the cardholder makes a purchase, the sub-merchant routes transaction data to the payment facilitator. The facilitator adds the required transaction and merchant identification data and sends it to the acquirer.

Common models are:

• Single-MID, where sub-merchants use the facilitator's own merchant ID.
• Multi-MID, where each sub-merchant has a separate merchant ID.

The processing and authorization flagging depend mainly on the boarding model and whether sub-merchants are boarded individually or transactions are initiated from the master store.

Payment URL lets a merchant send a payment link to customers through email invoice, WhatsApp, SMS, or similar channels. The link opens a Fiserv-hosted page where the customer can pay with an available payment method.

This is useful when goods are paid after delivery, no goods are shipped, monthly bills are paid, or a declined purchase should be retried by the customer.

The product provides:

• A way to request a payment URL for a specific amount through API.
• A hosted payment page where the customer selects the payment method.
• A hosted result page that shows the outcome and can offer retry behavior.

There are two related solutions: one connected to the Hosted Payment Page and one connected to the newer Checkout solution.

Recurring payment features are used where a single one-off payment is not sufficient, for example for monthly subscriptions or payments split across several months.

Visa Installments lets consumers split purchases into equal monthly installments over a selected period. This helps spread larger costs over multiple months instead of paying the full amount upfront.