For: IT contacts, finance directors, and operations managers requiring a technical understanding of Prommt's payment flows.
System architecture — Prommt's position in the payment stack
Prommt operates as a payment facilitation layer — not a payment processor. Prommt sits between the merchant and the payment gateway, handling request delivery, checkout hosting, and payment status synchronisation. Card transaction processing, authorisation, and fund settlement are handled entirely by the connected payment gateway.
The three-party architecture:
Layer | System | Responsibility |
Request and checkout | Prommt | Payment request generation and delivery (email / SMS / link), checkout page hosting, 3DS2 challenge initiation, payment status update, dashboard reporting |
Transaction processing | Payment gateway (e.g. Adyen, FreedomPay, Elavon, Global Payments, Authipay) | Authorisation request routing, issuer communication, 3DS2 authentication processing, PSP reference generation, settlement batching, fund transfer to merchant bank account |
Card network | Visa / Mastercard / Amex / other scheme | Interchange routing between acquirer and issuer, scheme rules enforcement, chargeback and dispute adjudication |
Prommt has API-level integration with the connected payment gateway. Prommt submits payment data to the gateway and receives authorisation responses. Prommt has no integration with card networks directly and no visibility into the gateway's downstream settlement operations.
Card payment flow — technical detail
Request delivery
When a payment request is sent, Prommt generates a unique tokenised checkout URL and delivers it via the selected channel — email, SMS, or as a copyable link. The URL is single-use: it is tied to a specific payment request record and expires on authorisation, cancellation, or after 5 failed attempts.
Checkout and card data capture
The customer opens the URL and lands on the Prommt-hosted checkout page. Card data — PAN, expiry, and CVV — is entered directly into the checkout. Prommt's checkout is PCI DSS Level 1 certified. Card data is not stored in Prommt; it is passed directly to the payment gateway via encrypted payload at the point of submission.
3D Secure 2 authentication
All card payment requests processed through Prommt use 3D Secure 2 (3DS2) — the EMV standard mandated under Strong Customer Authentication (SCA) regulations across the UK and EEA.
When the customer submits their card details, Prommt initiates a 3DS2 authentication request. The gateway passes this to the card network's directory server, which routes to the card issuer's Access Control Server (ACS).
The issuer's ACS determines the authentication method:
Frictionless flow — the ACS authenticates the cardholder silently using device fingerprinting, transaction history, and risk scoring. No customer action required. The authentication result is returned in the background.
Challenge flow — the ACS determines additional verification is required. The customer is redirected to their bank's authentication interface — typically a one-time passcode delivered by SMS, or an in-app push approval from their mobile banking application.
On successful authentication, the ACS returns an Authentication Value (AV) and an ECI (Electronic Commerce Indicator) code to the gateway. Prommt surfaces the ECI code in the Payment Gateway Response field on the payment record.
ECI Code | Scheme | Meaning | Liability |
05 | Visa | Full 3DS2 authentication | Shifts to issuer |
02 | Mastercard / Amex | Full 3DS2 authentication | Shifts to issuer |
06 | Visa | Attempted authentication | Partial — varies |
01 | Mastercard / Amex | Attempted authentication | Partial — varies |
07 | Visa | No authentication | Remains with merchant |
00 | Mastercard / Amex | No authentication | Remains with merchant |
On completed 3DS2 authentication (ECI 05 / 02), fraud liability shifts from the merchant to the card issuer. Prommt applies 3DS2 to all card transactions as standard — ECI 07 or 00 on a Prommt payment request is not expected and should be investigated. See Understanding ECI codes on failed payments.
Authorisation request and response
Following successful authentication, the gateway submits an authorisation request to the card issuer via the card network. The issuer returns one of:
Approved — the transaction is authorised. The gateway generates a PSP Reference (also referred to as Transaction ID or Gateway Reference depending on provider) and returns it to Prommt alongside the authorisation code.
Declined — the issuer declines the transaction and returns a decline reason code. The gateway maps this to a human-readable Payment Gateway Response which Prommt displays on the payment record. The customer is notified of the failure and can retry. After 5 failed attempts, the checkout URL is invalidated.
Common decline codes surfaced in the Prommt Payment Gateway Response field include: Do Not Honour, Insufficient Funds, Expired Card, Authentication Failed, Transaction Not Permitted. See [Troubleshooting: individual card declines and payment failures] for a full reference.
On approval, Prommt updates the payment record status to Paid and invalidates the checkout URL to prevent duplicate charges.
Settlement and fund transfer
Following authorisation, the payment gateway holds the authorised transaction in a settlement queue. Settlement is a separate operation from authorisation and is handled entirely by the gateway.
The gateway batches authorised transactions — typically on a daily cut-off schedule — and submits them through the acquiring bank for net settlement. The acquiring bank transfers the settled funds to the merchant's nominated bank account, less any gateway fees, interchange costs, and scheme fees.
Settlement timeline: typically 2–5 business days from the authorisation date, depending on the gateway provider, acquiring bank, and merchant banking arrangements.
Prommt has no API connection to the gateway's settlement system. Once a transaction is authorised and the Prommt payment status updates to Paid, Prommt's visibility of that transaction ends. Prommt cannot report on:
Settlement batch inclusion or timing
Net settlement amounts after fee deductions
Fund transfer dates or bank credit timings
Settlement discrepancies or reconciliation variances
All settlement queries must be directed to the payment gateway provider, referencing the PSP Reference from the Prommt payment record.
Pay by Bank flow — technical detail
Pay by Bank uses the open banking infrastructure to initiate a Payment Initiation Service Provider (PISP) transaction — a real-time push payment from the customer's bank account directly to the merchant.
Infrastructure
UK: Faster Payments Service (FPS) — typically settles within seconds to minutes, maximum 2 hours
EEA: SEPA Instant Credit Transfer (SCT Inst) or SEPA Credit Transfer (SCT) — instant where the receiving bank supports SCT Inst; otherwise T+1
Transaction flow
The customer selects Pay by Bank at the Prommt checkout.
The customer selects their bank from the list of supported open banking providers.
The customer is redirected to their bank's authorised interface (ASPSP — Account Servicing Payment Service Provider) via a secure handoff.
The bank presents the payment details for the customer's review, including the merchant's verified name confirmed via Confirmation of Payee (CoP) — a mandatory verification layer under UK Payment Systems Regulator rules.
The customer authenticates using their bank's standard Strong Customer Authentication method (biometric, PIN, or app approval) and approves the payment.
The bank (acting as ASPSP) executes the payment instruction over Faster Payments or SEPA. The funds move directly from the customer's account to the merchant's nominated account.
The payment confirmation is returned to Prommt via the open banking provider. Prommt updates the payment status to Paid.
Key characteristics
No card scheme involved — there is no interchange, no scheme fee, and no acquirer in the payment chain
No chargeback mechanism — push payments over Faster Payments and SEPA do not support third-party payment reversal post-execution. Once the customer has approved and the bank has executed, the payment cannot be reversed by a third party
APP fraud liability — the UK PSR's mandatory APP fraud reimbursement framework (effective October 2024) applies to Faster Payments. Prommt's Confirmation of Payee integration and KYB verification of all merchants provide documented fraud-prevention evidence should a dispute arise
Settlement — funds arrive directly in the merchant's bank account via Faster Payments or SEPA, without gateway batching or settlement lag
Prommt's data boundary — what we can and cannot report
Data point | Prommt visibility |
Payment request sent / delivered | Yes |
Customer opened checkout | Yes — via click tracking |
Authentication outcome (ECI code) | Yes — surfaced in Payment Gateway Response |
Authorisation outcome (approved / declined) | Yes — surfaced in Payment Gateway Response |
PSP Reference / Transaction ID | Yes — surfaced in Payment Gateway Response |
Decline reason code | Yes — surfaced in Payment Gateway Response |
Settlement batch inclusion | No |
Net settlement amount (post fees) | No |
Fund transfer date to merchant bank | No |
Bank credit confirmation | No |
For any data point marked No, the authoritative source is the payment gateway's merchant portal (e.g. Adyen Customer Area, FreedomPay Merchant Portal) or the merchant's acquiring bank.
How to identify your connected payment gateway
Go to Settings → Card Gateway in your Prommt dashboard. The gateway connection section confirms which gateway is active — for example, "Your account is connected to Adyen".
If no gateway is showing as connected, contact Prommt Support. Do not attempt to reconnect the gateway yourself — gateway credentials are managed by Prommt on the merchant's behalf.
Troubleshooting
A payment shows as Paid in Prommt but funds have not arrived in our bank account. Prommt's data boundary ends at authorisation confirmation. Retrieve the PSP Reference from the Payment Gateway Response field on the payment record in View Payments, then log into your gateway's merchant portal and locate the transaction. If the transaction is in the settlement queue or has settled, the delay is in the acquiring bank's transfer cycle. Contact your gateway provider if the transaction cannot be located or if there is a settlement discrepancy.
A customer failed authentication and cannot complete payment. Check the ECI code and Payment Gateway Response on the failed payment in View Payments. Authentication failures indicate an issuer-side or cardholder-side problem — outdated phone number registered with the bank, expired app session, or a corporate card where the registered cardholder is not the one completing the payment. Prommt cannot intervene in the 3DS2 authentication flow. See Understanding 3D Secure 2 and Strong Customer Authentication.
The Payment Gateway Response field is blank on a failed transaction. A missing gateway response indicates the transaction did not reach the gateway — it failed before submission. This is typically a connectivity or configuration issue. Check that your account is in Live Mode and the gateway is showing as connected at Settings → Card Gateway. See Troubleshooting: all payments failing on your account.
The PSP Reference is missing from the payment record. A PSP Reference is only generated on a completed authorisation attempt — approved or declined with a gateway response. If no PSP Reference is present, the transaction was abandoned before submission (customer closed the checkout) or failed before reaching the gateway. No gateway-side record will exist.
A Pay by Bank payment is showing as Paid but the funds have not arrived. Pay by Bank payments settle via Faster Payments (typically within minutes) or SEPA. If the payment status in Prommt is Paid and funds have not arrived within 2 hours for a UK Faster Payments transaction, check your bank account and confirm the receiving sort code and account number on file. Contact your open banking provider if the payment cannot be traced.