PIS vs card rails: a practical cost and settlement timing comparison for fintech builders

Cost and settlement comparison chart between PSD2 payment initiation and card network rails

Payment initiation via open banking (PIS) and card network payments both move money, but they do so through structurally different mechanisms, with different cost profiles, different failure modes, and different regulatory contexts. This comparison is for engineering and product teams deciding which rails to use — or when to offer both.

How the mechanics differ

A card payment routes through a four-party scheme (cardholder, issuer, acquirer, scheme — Visa or Mastercard). The acquirer guarantees funds to the merchant at the point of authorisation, and the issuer settles with the acquirer through the scheme's clearing cycle. The merchant receives settlement T+1 or T+2 in most European markets.

A PIS payment is a push payment initiated directly from the payer's bank account to the payee's bank account. In the UK, this routes through Faster Payments (settlement typically in seconds). In the EU, it routes through SEPA Credit Transfer (T+1 for standard SCT) or SEPA Instant Credit Transfer (SCT Inst, settlement in seconds). There is no acquiring bank and no card scheme in the chain — only the payer's bank (as ASPSP), the TPP (as PISP), and the payee's bank.

This structural difference has direct consequences for cost, speed, chargeback risk, and SCA requirements.

Cost comparison

Card processing costs consist of interchange (paid to the card issuer), scheme fees (paid to Visa/Mastercard), and acquirer margin. For consumer card transactions in the UK and EU, interchange is regulated: 0.2% for debit cards, 0.3% for credit cards, under the Interchange Fee Regulation. Acquirer fees add typically 0.1–0.5% of transaction value plus a per-transaction flat fee. All-in, a typical UK business paying card fees pays roughly 0.4–1.2% of transaction value depending on card type, acquirer, and volume tier.

PIS via open banking carries no interchange because there is no card issuer in the chain. TPP fees (what an aggregator like BankLyra charges per PIS call) are typically a flat per-transaction fee rather than a percentage. For high-value transactions — mortgage deposits, investment contributions, insurance premiums — the percentage saving is material. For a £5,000 transaction, the card processing cost at 0.8% is £40; a flat-fee PIS transaction might cost pence.

The break-even point where PIS becomes cheaper than cards depends on your acquirer's rate and the PISP's per-transaction fee. For transaction values above roughly £200–300 in the UK market, PIS economics typically favour open banking — assuming you can accept the reliability and authentication friction trade-offs described below.

Settlement timing

UK Faster Payments settles in seconds for most payments, with a statutory limit of two hours. The payer's account is debited in real time; the payee's account receives the credit within the same working day in the overwhelming majority of cases.

SEPA Instant Credit Transfer (SCT Inst) also settles in seconds, but it requires both the payer's bank and the payee's bank to be participants in the SCT Inst scheme. As of 2025, EU banks above a certain asset threshold are required to offer SCT Inst under the Instant Payments Regulation (IPR), but participation is still not universal — particularly among smaller credit unions and cooperative banks.

Card payments deliver a provisional guarantee at authorisation, but actual settlement is T+1 or T+2. For merchants who need confirmed funds quickly (crypto exchanges, insurance top-ups, investment platforms), the Faster Payments settlement window is a significant operational advantage over cards.

Chargeback exposure

Card payments carry chargeback rights. A cardholder can initiate a chargeback for unauthorised transactions, non-delivery, or goods not as described — and the issuing bank reverses the transaction charge to the merchant's acquirer, who then passes the reversal to the merchant. Chargeback rates vary by sector and merchant type; high-risk categories (travel, digital goods) face elevated rates.

PIS payments have no chargeback mechanism in the card-scheme sense. A push payment from the payer's account to the payee's account is final once settled. Under UK Faster Payments, the only reversal mechanism is the payer requesting a return through their bank, which the receiving bank can decline. PSPs offering open banking payments are expected to participate in the Contingent Reimbursement Model (CRM) code or equivalent protections against authorised push payment (APP) fraud — but this is not equivalent to automatic chargeback rights.

For merchants and platforms, this is both a benefit and a responsibility. Lower chargeback exposure reduces fraud-related costs; but PIS puts more of the authentication burden on the SCA flow — if a fraudulent payment is authorised through a compromised SCA, recovery options are limited compared to a card dispute.

SCA and the authentication handoff

Card payments trigger SCA through 3D Secure (3DS2) for online transactions — the card issuer manages the authentication challenge, and the merchant integrates with their payment service provider's 3DS implementation. From the merchant's perspective, 3DS is handled by the PSP's checkout widget; they do not need to implement SCA logic directly.

PIS requires your application to initiate the PISP consent flow, redirect the PSU to the ASPSP's authorisation screen (where SCA is performed by the bank's own mechanism), and then receive the callback before the payment proceeds. The payer's SCA experience is determined by their bank — if they use a bank with a poor mobile app or a slow SMS OTP flow, the friction is higher than a well-implemented 3DS challenge.

The authentication handoff also means the payer must leave your checkout flow to complete the payment. For payment flows where conversion is paramount — consumer e-commerce, for instance — this redirect friction needs to be weighed against the cost savings. For B2B payments, investment top-ups, and high-value consumer transactions where the payer expects to authenticate, it is much less of a concern.

When PIS is the better choice

  • High-value transactions where percentage-based card fees are substantial (above approximately £200–300 per transaction)
  • B2B payments where the payer expects the process to involve bank authentication and chargeback rights are not expected
  • Investment and savings platforms where confirmed settlement timing matters and the user relationship is trusted
  • Recurring top-ups within VRP parameters in the UK, where subsequent payments can proceed without per-payment SCA
  • Platforms in sectors with high chargeback rates who need to reduce dispute-related losses

When cards are the better choice

  • Consumer e-commerce where guest checkout and saved card credentials are critical to conversion
  • Cross-border payments to non-SEPA regions — PIS does not extend beyond the SEPA area and UK Faster Payments
  • Situations where chargeback rights benefit the buyer experience — consumer protection expectations in travel and digital goods markets
  • Low-value, high-frequency transactions where flat-fee PIS costs exceed the percentage card cost
  • Markets where SCT Inst participation is incomplete and T+1 card settlement is acceptable

Running both rails in parallel

Most platforms of any scale end up offering both. Cards handle the convenience tier — low-value, consumer-facing, where stored card credentials and Apple Pay integrations do the heavy lifting on conversion. PIS handles the high-value tier — investment contributions, account funding, B2B invoices — where the economics justify the additional authentication step and the product team is willing to design the redirect flow properly.

The integration consideration when running both: your payment status data model must accommodate two settlement semantics. Card payments are authorised then settled; PIS payments (via Faster Payments or SCT Inst) are either initiated-and-pending or initiated-and-confirmed with no intermediate authorised state in the card sense. Your order management and reconciliation logic needs to handle these distinct state machines rather than forcing card settlement semantics onto PIS transactions.