Glossary

An authentication protocol that adds an extra layer of security for online card payments. The customer verifies their identity with their bank.

The second version of 3-D Secure, providing a better user experience with frictionless authentication for low-risk transactions.

A bank or financial institution that processes card payments on behalf of the merchant.

The process of verifying a payment method and reserving funds without actually transferring them. The funds are held on the customer's account.

The time period during which an authorisation remains valid for capture, typically 7 days for card payments (varies by network/issuer).

A capture method where authorisation and capture happen in a single step. Funds are immediately transferred upon successful authorisation.

The first 6-8 digits of a card number that identify the issuing bank and card type. Used for routing decisions.

A configuration in Peach that groups payment settings, connectors, and routing rules for a specific business unit or use case.

The process of collecting previously authorised funds. This is when money actually moves from the customer to the merchant.

A 3DS authentication flow where the customer must actively verify their identity, typically via OTP, biometrics, or app confirmation.

A payment reversal initiated by the customer's bank, typically due to a dispute. The merchant may need to provide evidence to contest it.

A payment initiated when the customer is present and actively participating, such as a checkout or subscription signup.

A unique key returned when creating a payment intent. Used by the frontend SDK to securely complete the payment without exposing your API key.

A payment processor or gateway integrated with Peach Payments (for example, Stripe, Adyen, Checkout.com). Peach Payments routes payments to connectors based on your configuration.

A formal disagreement about a charge, initiated by the cardholder through their bank. May result in a chargeback if not resolved.

Automatically retrying a failed payment with an alternative connector to improve success rates.

A 3DS2 flow where the issuer approves the transaction without requiring customer interaction, based on risk assessment.

A feature that maps connector-specific error codes to standardised statuses for consistent handling across connectors.

The bank that issued the customer's payment card. Responsible for authorising transactions.

A record of customer authorisation for future payments. Required for recurring charges and merchant-initiated transactions.

A capture method where authorisation and capture are separate steps. Useful when the final amount may change or you want to capture upon fulfilment.

A payment initiated by the merchant without the customer being present, such as a subscription renewal or delayed charge.

A secure token provided by card networks (Visa, Mastercard) that replaces the actual card number for stored credential transactions.

A payment made when the customer is not present. Requires prior authorisation (mandate) and stored credentials.

A payment made while the customer is actively engaged with your application. Customer can provide authentication if needed.

Capturing less than the full authorised amount. The remaining authorisation is typically released back to the customer.

Refunding only a portion of the original payment amount, often used for partial returns or price adjustments.

A single try to process a payment through a connector. A payment can have multiple attempts if retries or fallbacks occur.

A representation of your intent to collect payment from a customer. It tracks the lifecycle of the payment from creation to completion.

The means by which a customer pays, such as a credit card, bank transfer, or digital wallet.

The specific type within a payment method category. For example, within 'card', types include credit, debit, and prepaid.

Sending money from your account to a recipient, such as a seller, affiliate, or for refunds via original payment method.

Payment Card Industry Data Security Standard. A set of security requirements for handling cardholder data.

Payment Services Directive 2. European regulation that mandates Strong Customer Authentication and enables open banking.

Returning funds to a customer for a completed (captured) payment. Can be full or partial.

The process of contesting a chargeback by submitting evidence that the transaction was legitimate.

A European regulatory requirement (PSD2) mandating two-factor authentication for many online payments in the EEA.

The process of transferring captured funds from the payment processor to the merchant's bank account.

Peach's ability to automatically route payments to the optimal connector based on rules like cost, success rate, or geography.

Replacing sensitive card data with a non-sensitive token. The actual card details are stored securely by the payment processor.

Cancelling an authorisation before capture. No funds are transferred and the hold on the customer's account is released.

An HTTP callback that notifies your server of payment events (success, failure, disputes) in real-time.