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 surrogate for the card number, issued by the card network (Visa, Mastercard) and restricted to one merchant or domain, used in place of the card for stored credential transactions. It survives card reissue, and a stolen token is worth far less than a stolen card number — but it is still account data, and holding one does not put you outside PCI DSS.

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. The security requirements that apply wherever account data is stored, processed or transmitted. Account data means cardholder data — the card number, expiry, cardholder name and service code — plus sensitive authentication data, such as the CVC, track data, PINs and a token cryptogram. Sensitive authentication data may not be retained once a payment is authorised.

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 card data with a surrogate value, with the card details held by the payment processor instead of by you. How much it reduces your PCI DSS scope depends on what the token can do: one that can be used to initiate a payment is still account data and still has to be protected.

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.