Gateway Services

The payment page is the customer facing part of a gateway, and it must be fast, secure and easy to use. A hosted payment page redirects the customer to a gateway page that displays the order amount, the merchant name, and the available payment methods, while a checkout embedded in the merchant site keeps the customer on the same page and calls the gateway through an application programming interface. In both cases the card details go directly to the gateway, not to the merchant server, which keeps the merchant outside the strictest PCI DSS scope. A well designed page supports saved cards, one click checkout, address autofill and clear error messages, because every extra step or confusing message increases the chance that a customer abandons the purchase. The token vault is the secure store where a gateway keeps card details after the first payment. Instead of storing the real 16 digit card number, the gateway stores a token, which is a random reference such as tok_8f3k2m9q, and maps it to the card in an encrypted vault. The merchant stores only the token, so a breach of the merchant database does not expose card numbers. When a returning customer pays again, the merchant sends the token and the gateway retrieves the real card details from the vault. Under Reserve Bank of India rules, merchants in India must use tokenization through the card network or the gateway, and must not store the actual card number, CVV or expiry date on their own systems. Fraud screening protects the merchant from stolen cards, fake orders and account takeover. A gateway fraud engine checks the card country against the billing country, the velocity of attempts from one device or internet address, the order value against the customer history, and the result of 3D Secure authentication, which asks the customer to confirm the payment with a one time password or a bank application approval. High risk transactions can be blocked, sent for manual review, or allowed with extra checks. For example, a first time order of 85,000 rupees for electronics, paid with a card issued in another country and shipped to a different address, would score high and trigger a review before capture. Retry logic and webhooks keep payments moving when something fails. If an authorization fails because of a temporary network error, the gateway can retry the request with the same acquirer or route it to a backup acquirer, without asking the customer to enter card details again. An idempotency key, which is a unique value sent with the original request, prevents the retry from charging the customer twice. Webhooks are server to server notifications that the gateway sends to the merchant when the payment status changes, for example payment authorized, payment captured, refund processed, or chargeback received. The merchant system listens for these events and updates the order status automatically, so the warehouse ships only after a confirmed capture. Reporting closes the loop for finance, operations and reconciliation teams. A gateway dashboard shows daily transaction volume, approval rates by payment method, failure reasons, refund totals and settlement amounts. The merchant can download a settlement report that lists each transaction, its order identifier, its authorization code, the gross amount, the fee deducted and the net settlement amount. Reconciliation teams match the gateway report against the bank statement and the order management system, and investigate any mismatch, such as a captured payment that never settled or a refund that was processed twice. Good reporting turns a gateway from a simple pipe into a control point for the whole payment operation.