Payment FAQs

A payment gateway is the technology that securely captures and transmits a customer’s payment details from a checkout page to the systems that authorise the transaction. It acts as the digital link between a customer, a merchant’s website or app, and the banks involved in approving or declining the payment.

Gateways encrypt card and bank data in transit, run fraud checks, and return a response within seconds. Businesses accepting payments online typically connect a gateway through an e-commerce integration or build directly against a payment API, so the gateway sits behind their own checkout rather than redirecting customers elsewhere.

A payment processor is the company that handles the technical and financial steps of moving money from a customer’s bank to a merchant’s account once a transaction is authorised. It sits between the payment gateway, the card networks (such as Visa or Mastercard), and the banks, coordinating authorisation, settlement, and fund transfer.

In practice, many providers combine gateway and processor functions into a single platform, so merchants only need one integration to accept, authorise, and settle payments, with reporting and reconciliation handled automatically once funds land.

A payment service provider (PSP) is a company that gives merchants the tools to accept multiple payment methods, such as card, pay-by-bank, and digital wallet, through one platform, without needing separate contracts with each bank or card network. A PSP typically combines a gateway, processing, reporting, and account management into a single service.

This differs from a traditional merchant account set up directly with an acquiring bank, where the business holds its own dedicated account rather than sharing infrastructure with other merchants under the provider. Most merchants choose a PSP specifically to avoid managing that relationship themselves.

A payment gateway captures and encrypts the payment details and passes them along the chain. A payment processor handles what happens next: routing the transaction to the right bank, getting it authorised, and settling the funds into the merchant’s account. The gateway is the entry point; the processor is the engine that moves the money.

Most modern providers bundle both functions together behind a single payment API, so merchants deal with one integration rather than stitching together separate gateway and processor contracts, and can monitor the whole flow through payment operations.

PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements that any business handling card payments must meet to protect cardholder data. It covers areas such as encryption, network security, access controls and regular testing, and applies to merchants, processors, and gateways alike.

Working with a PCI-compliant provider reduces a merchant’s own compliance burden, since most of the sensitive card data handling, along with fraud screening tools designed to prevent fraud, is managed within the provider’s certified infrastructure rather than the merchant’s own systems.

3D Secure (3DS) is an extra layer of security for online card payments that verifies a customer’s identity before a transaction is approved, typically through a one-time passcode, biometric check, or banking app confirmation. It’s part of the technical standard behind Strong Customer Authentication (SCA), required for most online card payments in the UK and EU.

3DS shifts liability for certain types of fraud away from the merchant when used correctly, making it one of the core tools behind any strategy to prevent fraud on card-not-present transactions.

A chargeback is a forced reversal of a card payment, initiated by the customer’s bank rather than the merchant, usually after a cardholder disputes a transaction as fraudulent, unauthorised, or not as described. The funds are pulled back from the merchant’s account while the dispute is investigated, and the merchant can typically submit evidence to challenge it.

Chargebacks differ from refunds because the merchant doesn’t initiate them and often has a limited time to respond with supporting evidence. Tools like pre-authorisation and transaction verification, covered under fraud prevention, are designed to stop disputable transactions from going through in the first place rather than fighting them after the fact.

Tokenisation replaces sensitive card details with a randomly generated string of characters (a “token”) that has no exploitable value if intercepted. The token can be used to process future payments or refunds without the merchant ever storing the actual card number.

This is what makes repeat payments and saved-card checkouts possible without repeatedly asking customers for their details, and it also narrows a merchant’s PCI DSS scope, since tokenised data isn’t considered sensitive cardholder data under the standard.

The acquiring bank is the financial institution that holds a merchant’s account and receives each payment on the merchant’s behalf. The issuing bank is the customer’s own bank, the one that issued their card and approves or declines the transaction based on available funds and fraud checks. Every card payment involves both the issuing bank authorising the funds and the acquiring bank ultimately depositing them with the merchant.

Providers that aren’t banks themselves typically work alongside FCA-regulated acquiring partners to handle this side of the transaction rather than holding merchant funds directly.

Online payment processing happens in a few seconds across several steps: a customer enters their card or bank details at checkout, a payment gateway encrypts and forwards that data, the customer’s issuing bank checks funds and approves or declines it, and the payment processor settles the approved funds into the merchant’s account. The whole exchange typically completes before the customer sees the confirmation page.

Merchants don’t need to build or manage each of these steps separately. A payment API or e-commerce integration handles the gateway and processing side, while reporting gives visibility into what’s been captured, authorised, or declined.

To accept credit card payments on a website, a business needs a merchant account, a payment gateway to capture card details securely, and a way to connect that gateway to the checkout flow. This can be done either through a hosted payment page or a direct API integration. Most providers bundle all three into one setup.

The simplest route for many businesses is a hosted checkout, such as a Blink page, which handles the card entry and security without needing custom development. Businesses wanting more control over the checkout’s look and feel typically build on a payment API or use an e-commerce integration for platforms like WooCommerce or Magento.

Integrating a payment gateway into an e-commerce site involves connecting your store’s checkout to the gateway’s API (or a pre-built plugin, if your platform supports one), so card and bank details are sent securely to the gateway rather than handled by your own server. Most e-commerce platforms support this through either a plugin or a documented API.

For platforms like WooCommerce, Magento, or GiveWP, this can be done through an e-commerce integration without custom code. For a fully custom build, developers typically work directly with a payment API and reference full technical documentation to handle authentication, payment creation, and webhooks.

Funds from a card transaction are typically available the next working day after the payment is taken, though this varies by provider and payment method. Open banking transactions can settle the same day, since the payment moves directly between bank accounts rather than through the card networks.

Settlement speed also depends on how the transaction was captured. A standard sale settles automatically, while a delayed capture or pre-authorisation only starts the settlement clock once the merchant actively captures the held funds. This is worth planning around for businesses that take deposits well ahead of delivering a service.

Recurring or subscription billing is set up by capturing a customer’s payment details once, tokenising them for security, and scheduling future charges against that token at agreed-upon intervals, without requiring the customer to re-enter their details each time. The customer’s consent to future charges is captured upfront as part of the setup.

This is handled through a repeat payments feature, which automates the charge schedule and consent tracking. It’s commonly used for memberships, instalment plans, and ongoing service contracts where the billing amount and frequency are known in advance.

A refund is issued by initiating a reversal on the original transaction through your payment dashboard or API, returning some or all the funds to the customer’s original payment method. Unlike a chargeback, the merchant initiates a refund voluntarily, and it’s usually processed within a few business days.

Refunds, along with the original payments they relate to, are automatically reflected in reporting and reconciliation, so there’s no need to manually track which transactions have been partially or fully refunded.

Disputing a chargeback means submitting evidence to the customer’s issuing bank, through your payment provider or acquirer, that shows the transaction was legitimate and authorised, such as proof of delivery, signed agreements, or authentication records like 3D Secure logs. The bank then reviews the evidence and decides whether to uphold or reverse the chargeback.

There’s usually a strict window to respond once a chargeback is raised, so having transaction details, authentication logs, and communication records easily accessible matters. Reducing how often chargebacks happen in the first place, through the tools covered under fraud prevention, is generally a more effective strategy than winning disputes after the fact of fraud.

Payment processing fees typically range from around 1% to 3.5% of each transaction value, depending on the card type, transaction method, and provider. Card-not-present (online) transactions usually cost more than in-person chip-and-PIN payments, and premium or business cards incur higher rates than standard debit cards.

Rather than one flat industry rate, most providers price based on turnover and transaction mix. Blink Payment builds a bespoke plan for each business, with platform access starting from £25 a month and card processing rates set according to monthly turnover, offered as either a blended rate or Interchange++ (interchange plus scheme plus acquiring fee) pricing.

Payment gateway fees usually take one of two forms: a small per-transaction fee, a monthly platform or licence fee, or both combined. Some providers fold the gateway fee into a single all-in processing rate rather than billing for it separately.

Blink Payment bundles gateway access into its platform fee rather than charging separately for it, so a business connecting through the payment API or an e-commerce integration sees one combined monthly and per-transaction cost covering the whole payment flow, starting from £25 a month for platform access.

Some payment processors carry fees beyond the headline transaction rate, including PCI compliance fees, chargeback fees, monthly minimums, early termination fees, or currency conversion charges. These aren’t necessarily hidden in the sense of being concealed, but they’re often left out of a provider’s advertised rate and only appear in the full terms.

With Blink Payment, there are no setup or hidden fees on the pricing page: the price quoted is the price paid each month, and if a business’s needs change, a new quote is issued rather than an unexplained charge appearing.

An interchange fee is the fee paid by a merchant’s acquiring bank to the customer’s card-issuing bank every time a card transaction is processed. It typically ranges from about 0.2% to 0.3% for regulated UK and EU consumer debit and credit cards, though rates are higher for commercial cards and cards issued outside the UK/EU. Interchange fees are set by the card networks (Visa, Mastercard) and capped by regulation in the UK and EU for most consumer cards.

Interchange is only one part of the total cost a merchant would pay. On top of it sits the card scheme fee and the acquirer’s own markup, which together make up the total rate. Blink Payment offers Interchange++ pricing through its acquiring partners, AIB, Elavon, and Cashflows, which breaks the interchange, scheme and acquiring fee out separately rather than folding them into one blended rate, giving merchants visibility into what they’re paying for each part.

Some merchant accounts and payment providers charge a fixed monthly fee on top of per-transaction rates, often covering account management, reporting access, or a minimum monthly processing volume. Others operate on a pay-as-you-go basis with no monthly fee at all, charging purely per transaction.

Blink Payment’s platform access starts from £25 a month, with the monthly rate dependent on which products a business uses, its turnover, and how it operates. Open banking transfers are typically charged at 0.25% per transaction (minimum 20p, maximum £4), and Direct Debit at 1% plus £0.20 per transaction, capped at £4, on top of the monthly platform fee.

Yes. Blink Payment uses PCI Level 1 compliant technology, the highest tier of card data security certification, along with encrypted payments, secure card tokenisation, and real-time fraud checks on every transaction. These measures are built into the platform rather than being optional add-ons that a merchant has to configure separately.

Security sits alongside a wider set of protections covering fraud prevention, authentication, and dispute handling. The same infrastructure protecting card data also works to reduce chargebacks and fraudulent transactions before they happen.

Customer payment data is protected primarily through encryption and tokenisation: card details are encrypted in transit and replaced with a secure token for storage, so the actual card number is never held on the merchant’s own systems. This is combined with PCI Level 1 compliant infrastructure, the strictest level of the Payment Card Industry Data Security Standard.

Tokenisation is also what makes features like repeat payments possible without merchants ever storing raw card data themselves, and it significantly narrows what falls inside a merchant’s own PCI DSS scope.

Yes. Blink Payment’s platform is built on PCI Level 1 compliant technology, the highest of the four PCI DSS compliance levels, reserved for providers processing the largest transaction volumes and held to the strictest security requirements.

This matters directly to merchants because using PCI Level 1 compliant technology significantly reduces their own compliance burden, since the most sensitive card data handling happens within Blink’s certified infrastructure rather than the merchant’s own systems.

Blink Payment operates as a technology provider, with acquiring and other regulated payment services delivered through its FCA-regulated partners: Elavon, AIB Merchant Services, OBN, and Cashflows. This means the regulated financial services side of a transaction, such as holding and moving merchant funds, sits with these partner institutions rather than with Blink Payment itself.

This is a common structure in the payments industry: many providers offer a single platform experience to merchants while relying on regulated banking partners behind the scenes to handle the regulated functions.

Blink Payment includes 3D Secure authentication, Strong Customer Authentication (SCA), real-time issuer checks, and fraud-minimising validation as standard, alongside chargeback protection. These tools work together to verify a transaction is legitimate before it’s approved, rather than only catching fraud after the fact.

Together, these sit under a broader fraud prevention approach that combines authentication at checkout with ongoing transaction monitoring, reducing both fraudulent payments and the chargebacks that follow them.

Opening a merchant account typically requires proof of identity for the business owners or directors, proof of trading address, along with recent bank statements and details of how the business takes and delivers payments. This lets the provider verify who they’re working with and meet anti-money laundering (AML) requirements.

For Blink Payment specifically, this includes photo identification and home address details for directors with significant ownership, proof of trading address dated within the last three months, and recent bank statements confirming where settlement funds should be paid.

Yes. Blink Payment is built for UK and EU small and medium-sized businesses, offering the same platform and tools regardless of a business’s size. Startups aren’t treated as a separate, restricted category.

Pricing is based on turnover and usage rather than a fixed enterprise-only package, a growing business’s costs scale with it, and the platform can be set up before volume is high, then adjusted as the business grows. The for merchants overview covers what’s included regardless of business stage.

“High-risk” is a classification payment providers use for industries that historically see higher rates of fraud, chargebacks, or regulatory scrutiny, such as gambling, adult content, cryptocurrency, travel, and subscription-based services with high cancellation rates. Being classified as high-risk usually means higher processing fees, rolling reserves, or more thorough underwriting rather than automatic exclusion.

This classification varies by provider, since each payment company sets its own risk appetite and list of accepted or excluded sectors.

Yes. Blink Payment supports multi-currency processing, including GBP, EUR, USD, and AUD, by configuring specific active currencies on your merchant account during onboarding. Additional currencies can be provisioned post-onboarding by contacting Blink Payment Support. Please note that while Blink Payment processes these multi-currency transactions, currency conversion rates and settlements are governed by your connected acquiring bank at the prevailing exchange rate at the exact time of the transaction.

This applies across Blink pages, payment requests, and card-present transactions, so a business isn’t limited to GBP-only checkout if its customers are based outside the UK.

Yes. Repeat payments can be set up directly from the Blink Payment platform, letting a business schedule automated recurring charges against a customer’s tokenised card details at agreed intervals, without needing to ask the customer to re-enter their details for each charge.

This is commonly used for memberships, instalment plans, and ongoing service contracts, and it works alongside reporting and reconciliation, so recurring charges are automatically reflected in a business’s cash flow view without manual tracking.

Yes, additional team members can typically be added to a merchant’s account so multiple people can access the platform.

Multi-user access is common for businesses where finance, sales, and account management teams all need visibility into payments, reporting, or reconciliation without sharing a single login.