Payment gateway features explained: What each one does and why it matters

Most merchants sign up to a payment gateway and take its features at face value. The provider lists recurring billing, tokenisation, and fraud screening, and that's assumed to be sufficient. In practice, how those features are implemented varies considerably between providers, and the gaps only become apparent when something goes wrong.

This guide covers the core payment gateway features available to UK and EEA merchants: what each one does, how it works technically, and the questions worth asking any provider before you commit.

Core payment gateway features: what they do and how they work

Payment gateway features are rarely self-explanatory. The same label ("recurring billing" or "fraud screening") can describe significantly different implementations depending on the provider. Knowing what each feature actually does gives UK and EEA merchants a basis for evaluating whether their current or prospective gateway is fit for purpose.

1. Transaction dashboard and reporting

A transaction dashboard is the primary interface through which merchants monitor payment activity in real time. Beyond displaying transaction status, a well-built dashboard surfaces reconciliation data, dispute activity, settlement timelines, and volume trends—information that matters for cash flow management and compliance reporting.

The dashboard should support:

• Customisable views and modular layout based on your reporting priorities.
• In-depth transaction data with filtering by date range, payment method, currency, and status.
• Settlement and reconciliation reports exportable for accounting and audit purposes.
• Real-time alerts for failed payments, disputes, and suspicious transaction patterns.

What to ask your provider: Does the dashboard support custom date ranges and exportable reconciliation reports? Is multi-currency reporting available if you process in more than one currency?

2. Recurring billing

Recurring billing automates the collection of payments on a scheduled basis (weekly, monthly, or annually) without requiring the customer to re-enter their card details each time.

The gateway stores payment credentials as a token (a non-sensitive reference to the original card data) and uses that token to initiate charges on the defined schedule. Price adjustments, plan upgrades, and contract renewals can be managed within the billing configuration without requiring a new payment authorisation.

For subscription-based businesses, recurring billing directly affects revenue retention. A missed scheduled charge that isn't recovered creates immediate revenue leakage, which compounds across a customer base. Effective recurring billing addresses this through configurable retry logic for failed payments, keeping involuntary churn in check.

Key capabilities to look for:

• Automated charge scheduling with configurable billing cycles and price adjustment support.
• Tokenised card storage that keeps the merchant outside direct PCI DSS cardholder data scope.
• Transaction monitoring and reporting within a single interface.
• Compliance with card scheme rules for stored credential transactions under MIT (Merchant-Initiated Transaction) frameworks.

What to ask your provider: How are failed payment retries handled, i.e., how many attempts are made, at what intervals, and is the retry logic configurable? Does the billing schedule support mid-cycle price changes without requiring a new authorisation?

3. Pay by link

Pay by link generates a unique, secure payment URL tied to a specific transaction amount, currency, reference, and expiry window.

The merchant sends the link to the customer via email, SMS, or any digital channel; the customer clicks through to a hosted payment page and completes the transaction without the merchant needing a full E-commerce checkout integration. Each link is tracked individually, and payment confirmation is logged against the originating reference in the gateway dashboard.

The feature is particularly useful for invoice-based businesses, telephone sales, and situations where a customer needs to complete a payment outside a standard checkout flow. Pay by link removes the friction of manual payment collection while keeping the transaction within a compliant, PCI DSS-scoped environment.

Key capabilities to look for:

• Automated link generation with configurable amount, currency, expiry, and reference fields.
• Single-use or multi-use link options depending on the payment scenario.
• Full transaction tracking and status reporting from the gateway dashboard.
• Branded or white-label hosted payment page at the link destination.

What to ask your provider: Can links be configured as single-use or multi-use? How is payment confirmation delivered—to the merchant, the customer, or both—and how quickly?

4. Virtual terminal

A virtual terminal is a browser-based interface that allows merchants to manually enter card details and process payments in real time, without the customer or their physical card being present.

The merchant accesses the terminal through their gateway dashboard, inputs the card number, expiry, and CVV provided by the customer, typically over the phone or via mail order, and submits the transaction directly.

Because the cardholder is not present to authenticate the transaction themselves, MOTO payments (mail order/telephone order) processed through a virtual terminal carry a different liability and compliance profile than standard card-present or 3DS2-authenticated transactions.

Merchants using virtual terminals need to understand how their provider classifies these transactions and what that means for dispute liability.

Key capabilities to look for:

• Support for major card schemes across multiple currencies and geographies.
• Transaction monitoring and reporting consistent with other payment channels in the gateway dashboard.
• Clear classification of MOTO transactions to ensure correct card scheme rules are applied.
• Configurable access controls to restrict terminal use to authorised staff only.

What to ask your provider: How are MOTO transactions classified within your system, and what does that mean for dispute liability? Is the virtual terminal covered under the same PCI DSS scope as the rest of the gateway, or does it carry separate compliance obligations?

5. Rebilling

Rebilling handles the recovery of failed transactions—it is distinct from recurring billing, which manages scheduled payment collection. When a charge fails due to insufficient funds, an expired card, or a temporary issuer decline, rebilling automatically reinitiates the transaction according to a pre-configured retry schedule, without requiring the customer to re-enter their payment details.

The distinction matters because not all gateways handle failed transaction recovery with the same degree of control. A gateway that retries at fixed intervals may trigger additional declines and, in some cases, card scheme penalties if retry attempts breach scheme rules on stored credential usage.

Well-implemented rebilling uses decline reason codes to inform the retry strategy—spacing attempts appropriately and avoiding retries where the decline indicates a permanent block.

Key capabilities to look for:

• Configurable retry schedules based on decline reason codes rather than fixed intervals.
• Tokenised card storage that enables retries without re-exposing cardholder data.
• Optimised payment acceptance rates through intelligent routing on retry attempts.
• Full PCI DSS compliance for stored credential handling across all retry attempts.

What to ask your provider: How many retry attempts does the system make, at what intervals, and is the retry logic configurable by decline type? How does your rebilling implementation comply with card scheme rules on merchant-initiated retry transactions?

6. Pre-authorisation and capture

Pre-authorisation places a temporary hold on funds in the customer's account without completing the charge. When the transaction is finalised, the merchant submits a capture request to convert the hold into a completed payment; if cancelled before capture, the hold is released with no charge applied.

The authorisation and capture steps can be triggered separately, which gives merchants flexibility where the final amount may differ from the initial hold, or where service delivery is confirmed after the initial booking.

Key capabilities to look for:

• Configurable hold periods that align with your fulfilment or service delivery timeline.
• Support for partial captures where the final charge differs from the authorised amount.
• Automatic hold expiry handling to avoid authorisation timeouts causing payment failures.
• Clear reporting of open authorisations, captured transactions, and released holds within the dashboard.

What to ask your provider: What is the maximum authorisation hold window before the hold expires? How are partial captures handled: can the merchant capture less than the original authorised amount, and what happens to the remainder?

7. 3DS2 and Strong Customer Authentication

3DS2 is the authentication protocol that implements Strong Customer Authentication (SCA), the two-factor verification requirement mandated under PSD2 for online card transactions across the UK and EEA.

It exchanges data signals between the gateway, card scheme, and issuing bank to determine whether to authenticate the transaction silently (frictionless flow) or prompt the cardholder to verify their identity (challenge flow). A well-configured 3DS2 integration sends richer signals to the issuer, increasing frictionless rates and reducing abandonment.

Key capabilities to look for:

• Full 3DS2 implementation compliant with PSD2 SCA requirements for UK and EEA transactions.
• Frictionless flow optimisation through rich data sharing with issuers.
• Correct exemption handling for low-value, MIT, and TRA-eligible transactions.
• Reporting on frictionless vs. challenge authentication rates to identify conversion impact.

What to ask your provider: What is your average frictionless authentication rate across your merchant base? How do you handle SCA exemptions: is TRA applied automatically, and at what threshold?

» Want the full regulatory picture? Find out how PSD2 and SCA affect specialist UK and EEA merchants

8. Tokenisation and card storage

Tokenisation replaces a customer's card number (the Primary Account Number, or PAN) with a non-sensitive reference string called a token, stored in a secure vault at the gateway or card network level.

Merchants that store tokens instead of PANs can significantly reduce the number of systems in PCI DSS scope, potentially lowering compliance complexity and breach risk. That is provided the tokenisation implementation meets PCI SSC guidelines and the token provider maintains their own PCI DSS compliance.

It also underpins recurring billing and rebilling: the token represents the customer's payment method and authorises future merchant-initiated charges without re-exposing card data.

Provider tokens are specific to the issuing gateway and are not portable. Network tokens, issued directly by Visa and Mastercard, are portable across acquiring relationships and typically achieve higher authorisation rates because issuers treat them as more secure than static credentials.

Key capabilities to look for:

• PCI DSS-compliant tokenisation that removes card data from the merchant's environment.
• Support for network tokens to improve authorisation rates and reduce issuer declines.
• Automatic token updates when a card is renewed or replaced.
• Clear documentation of token portability if the merchant changes provider.

What to ask your provider: Are the tokens you issue provider-specific or network tokens? What happens to stored tokens if we move to a different gateway: can they be migrated, and under what conditions?

9. Multi-currency processing

Multi-currency processing allows merchants to accept payments in the customer's local currency while settling in their preferred currency. FX markup is where significant variation exists between providers: the rate applied to a transaction is rarely the mid-market rate, and the margin added on top is not always disclosed clearly in standard fee schedules.

For merchants processing material cross-border volumes, that cumulative cost warrants the same scrutiny as transaction fees.

Cross-border routing also affects authorisation rates. Transactions processed through a local acquirer in the customer's market typically achieve higher approval rates than those routed cross-border. Merchants expanding across UK and EEA markets should confirm whether their provider supports local acquiring in the relevant geographies.

Key capabilities to look for:

• Acceptance in multiple currencies with settlement in the merchant's preferred currency.
• Transparent FX rate disclosure, including the markup applied above the interbank rate.
• Local acquiring support across UK and EEA markets to maximise authorisation rates.
• Multi-currency reconciliation reporting within the gateway dashboard.

What to ask your provider: How is your FX rate calculated, and what markup is applied above the interbank rate? Which acquiring regions do you support locally, and what authorisation rate difference can we expect between local and cross-border routing?

10. Fraud detection and screening

Gateway-level fraud screening evaluates transactions against risk rules before they reach the authentication or authorisation stage, using signals such as velocity checks, BIN analysis, device fingerprinting, and IP geolocation. It is distinct from 3DS2: screening happens at the gateway before submission to the issuer; 3DS2 is the issuer's authentication step that follows. The two work in sequence.

The key variable between providers is configurability. Fixed rules applied uniformly across a merchant base generate false positives that block legitimate transactions. Merchants with a distinct transaction profile need rules tuned to their patterns, not a generic risk model.

Key capabilities to look for:

• Configurable risk rules adjustable to the merchant's specific transaction profile.
• Velocity checks, BIN analysis, and device fingerprinting as standard screening signals.
• Manual review queue for borderline transactions rather than automatic declines.
• Reporting on declined transactions and false positive rates to support rule refinement.

What to ask your provider: Are fraud screening rules configurable at the merchant level, or applied uniformly across your platform? What is the typical false positive rate, and is there a manual review process for flagged transactions?

How Fibonatix's Paragon gateway delivers these features

The questions raised throughout this guide form the basis of any serious gateway evaluation. Paragon, Fibonatix's payment gateway, is built to satisfy them across functional and compliance dimensions.

On the functional side, Paragon brings card processing, virtual terminal, pay by link, recurring billing, rebilling, and pre-authorisation capture into a single platform. The dashboard surfaces real-time transaction monitoring, settlement visibility, chargeback tracking, and exportable reconciliation reports.

On compliance and security, Paragon operates at PCI DSS Level 1 and implements 3DS2 for SCA-compliant authentication across UK and EEA transactions. Tokenisation handles stored credential management, and fraud screening includes velocity checks and fraud scoring built into the transaction flow.

If you are reviewing your current setup against the questions raised in this guide, Fibonatix's payment consulting team can help you identify the gaps that matter and align gateway capability to your operational requirements.

Fibonatix (UK) Limited, company number 09738892, is authorised and regulated by the UK Financial Conduct Authority (FCA) as a Payment Institution (FRN 768776).