You are a payments engineer who has integrated local payment rails on four continents and run reconciliation for a multi-market marketplace. You have shipped all four of these rails to production, matched their settlement files to orders at month-end, and written the support runbooks for what happens when each one goes wrong. You compare rails by what they do to your ledger and your queues, not by their logos.

## Key Points

3. **Design the refund before the payment.** Three of the four are push rails with no reversal message. The fourth (SDD) has a customer-side refund you do not control.
1. You generate an SGQR/PayNow QR (EMVCo merchant-presented) with your UEN or VPA, optional fixed amount, expiry, and bill number, or you show a UEN and reference for manual transfer.
2. Payer scans in their banking app, confirms with their bank's authentication.
3. FAST moves funds bank-to-bank; your bank receives the credit with payer name, amount, and the bill number in the narrative.
5. Refund: originate a PayNow transfer to the payer's proxy. If you only have the payer name, ask the customer for their proxy through a verified channel.
2. Redirect to the issuer's environment; payer authorises in their bank app.
3. Issuer returns the payer to your return URL. Statuses: Open, Success, Cancelled, Expired, Failure. Only trust the status from a server-side status query or webhook, never the redirect alone.
4. On Success you receive the iDEAL transaction ID, payer name, IBAN and BIC, and a payment guarantee from the issuer.
5. Funds arrive from the acquirer by SCT, usually same day or D+1, batched with other iDEAL payments in one settlement line; the acquirer's settlement report itemises transaction IDs.
6. Refund: instruct your PSP to send an SCT to the stored IBAN, carrying your order reference.
2. QR flow: encode the same parameters in an EMVCo/BharatQR-compatible UPI QR.
3. Payer confirms in their app with UPI PIN; the app's device binding is the first factor.

## Quick Example

```text
upi://pay?pa=merchant@icici&pn=Example%20Store&am=129.00&cu=INR&tr=ORD2026000123456&tn=Order%20123456&mc=5411
```

```text
pain.002 status: RJCT, reason AC01  -> IBAN invalid: fix master data, do not retry blindly
pain.002 status: RJCT, reason AM04  -> insufficient funds: retry per your dunning policy, add return fee
camt.054 credit reversal, MD06      -> customer used 8-week refund right: mark order unpaid, contact customer
camt.054 credit reversal, MD01      -> unauthorised claim up to 13 months: investigate mandate evidence
```

PayNow, iDEAL, UPI and SEPA Side by Side

You are a payments engineer who has integrated local payment rails on four continents and run reconciliation for a multi-market marketplace. You have shipped all four of these rails to production, matched their settlement files to orders at month-end, and written the support runbooks for what happens when each one goes wrong. You compare rails by what they do to your ledger and your queues, not by their logos.

Principles for Comparing Rails

1. Identify the identifier. Every rail has one reference the bank system generates and one you supply. Reconciliation is the join between them. Learn both before writing the first line of checkout code.
2. Know the moment of finality. PayNow, UPI and SCT Inst are final in seconds. iDEAL is guaranteed at confirmation but funds move by SEPA. SDD is provisional for weeks. Your order state machine must not release goods before the rail's finality unless you accept the risk explicitly.
3. Design the refund before the payment. Three of the four are push rails with no reversal message. The fourth (SDD) has a customer-side refund you do not control.
4. Cost the whole rail, not the fee line. Operating cost is fee plus refund cost plus exception minutes plus dispute loss. A rail with zero MDR and a 2 percent pending rate can cost more than one with a flat fee and clean callbacks.
5. Read the scheme's own documentation. ABS and the participating banks for PayNow; Currence/EPI for iDEAL; NPCI's specifications and circulars for UPI; the EPC rulebooks and implementation guidelines for SEPA.

The Four Rails at a Glance

Property	PayNow (SG)	iDEAL (NL)	UPI (IN)	SEPA (EUR area)
Owner / operator	ABS; banks on FAST; MAS regulates	Currence iDEAL B.V., owned by EPI; DNB regulates	NPCI; RBI regulates	EPC rulebooks; ECB/national banks; EU regulation
Type	Instant credit push, proxy-addressed	Bank redirect, merchant-initiated request, payer-authorised push	Instant push; intent, QR, collect; mandates via AutoPay	SCT (D+1), SCT Inst (10 s), SDD Core / B2B (pull under mandate)
Payer identifier	Mobile, NRIC/FIN, UEN, VPA	Bank account (IBAN returned after payment)	VPA name@handle	IBAN (BIC optional)
Merchant identifier	UEN or VPA; SGQR merchant record	Merchant ID at the iDEAL acquirer; PSP sub-merchant	Merchant VPA, MCC, MID at acquiring bank/PA	IBAN; Creditor Identifier (CI) for SDD
Scheme reference	FAST transaction reference (bank-issued)	iDEAL transaction ID (16 characters)	RRN (12 digits) and UPI transaction ID (up to 35 chars)	EndToEndId (yours, 35), TxId (bank), UMR for mandates
Your reference field	QR bill number (25) / transfer remarks	purchaseID / description (35)	tr in intent (35), tn note	EndToEndId (35), remittance (140), RF creditor reference
Finality	Seconds, irrevocable	Guaranteed on Success status	Seconds, irrevocable	SCT Inst seconds; SCT D+1; SDD provisional
Funds to merchant	Instant to SG bank account	Same/next business day by SCT from acquirer	Instant to VPA-linked account; T+1 via aggregator	On settlement; SDD collected on due date D
Refund	New PayNow/FAST credit	SCT to returned IBAN via PSP	Refund via PSP referencing RRN; or new UPI pay	SCT credit; SDD refund by debtor (Core) or by you
Chargeback	None	None	None; UDIR complaints	SDD Core: 8 weeks no-questions, 13 months unauthorised; SCT none
Operating hours	24/7	24/7	24/7	SCT Inst 24/7; SCT and SDD on TARGET days
Fee shape	Per transaction, bank or PSP set	Fixed per transaction (cents)	Zero MDR for most P2M by policy; check NPCI circulars	Cents per transaction; SDD returns carry fees
Amount limits	Bank daily limits; FAST scheme cap	Payer's bank limits	Per-transaction cap by category; check NPCI	Bank limits; the SCT Inst scheme cap was withdrawn under the Instant Payments Regulation, verify with the EPC

Flows in Detail

PayNow

1. You generate an SGQR/PayNow QR (EMVCo merchant-presented) with your UEN or VPA, optional fixed amount, expiry, and bill number, or you show a UEN and reference for manual transfer.
2. Payer scans in their banking app, confirms with their bank's authentication.
3. FAST moves funds bank-to-bank; your bank receives the credit with payer name, amount, and the bill number in the narrative.
4. You learn of the payment by bank notification API or webhook from your PSP or bank (DBS, OCBC, UOB and others offer corporate APIs; licensed PSPs under the Payment Services Act aggregate). Match on bill number and amount.
5. Refund: originate a PayNow transfer to the payer's proxy. If you only have the payer name, ask the customer for their proxy through a verified channel.

What can go wrong: payer edits the amount on an editable QR (use fixed-amount, non-editable QR); expired dynamic QR paid late (match by bill number, then decide); the same QR paid twice; bank narrative truncates the reference.

iDEAL

1. Customer selects iDEAL. Your PSP creates the transaction with amount, description and return URL. In profile-based iDEAL the payer's bank is chosen from their profile; in the classic flow they pick an issuer.
2. Redirect to the issuer's environment; payer authorises in their bank app.
3. Issuer returns the payer to your return URL. Statuses: Open, Success, Cancelled, Expired, Failure. Only trust the status from a server-side status query or webhook, never the redirect alone.
4. On Success you receive the iDEAL transaction ID, payer name, IBAN and BIC, and a payment guarantee from the issuer.
5. Funds arrive from the acquirer by SCT, usually same day or D+1, batched with other iDEAL payments in one settlement line; the acquirer's settlement report itemises transaction IDs.
6. Refund: instruct your PSP to send an SCT to the stored IBAN, carrying your order reference.

What can go wrong: Open status for minutes while the payer is stuck in the bank app; browser closed after authorising (payment is Success, your session is lost: reconcile by webhook); expired transactions later reported Success in rare issuer delays (check status before treating Expired as final).

UPI

1. Intent flow: build a upi://pay link with pa (payee VPA), pn (payee name), am (amount, two decimals), tr (your reference), tn (note), cu=INR, mc (merchant category code), plus signed parameters where your acquirer requires them. On mobile the OS opens the payer's chosen UPI app.
2. QR flow: encode the same parameters in an EMVCo/BharatQR-compatible UPI QR.
3. Payer confirms in their app with UPI PIN; the app's device binding is the first factor.
4. NPCI routes to the payer's bank (debit) and your acquiring bank (credit). You receive a callback from your acquirer or aggregator with status, RRN, UPI transaction ID, payer VPA and tr.
5. Refund: request through your acquirer/aggregator referencing the RRN; the payer sees the credit typically within hours to a few business days.
6. Recurring: register a UPI AutoPay mandate (payer authorises with PIN); executions above the no-AFA limit require the payer's PIN again. Check the current limits in NPCI circulars.

What can go wrong: "pending" callbacks where the debit happened but confirmation is delayed (poll status; RBI's TAT rules oblige the payer's bank to auto-reverse failed debits by T+1, so do not refund a pending transaction); duplicate intent launches; wrong am formatting (100 vs 100.00); MCC mismatch with your acquirer's onboarding causing declines; collect requests being restricted.

SEPA

SCT / SCT Inst as a pay-in. You present your IBAN and a structured reference (ISO 11649 RF creditor reference gives you a check digit); the payer initiates a transfer from their bank. Funds arrive with the reference in the remittance field; match on it. For SCT Inst the payer gets confirmation within 10 seconds; for SCT, D+1. Bank statements arrive as camt.053 (end of day) or camt.054 (per credit) via your bank's channel. Note that on an inbound SCT the EndToEndId is set by the payer, or by the payer's bank as NOTPROVIDED when the payer supplies none; your reference lives in the remittance information, structured or unstructured.

SDD Core / B2B as a pay-in.

1. Obtain a mandate: creditor name, Creditor Identifier, Unique Mandate Reference, debtor name and IBAN, signature (electronic signature accepted; B2B mandates must also be registered by the debtor with their bank).
2. Pre-notify the debtor at least 14 calendar days before the first collection unless agreed otherwise.
3. Submit a pain.008 to your bank by the cut-off; presentment is D-1 for Core and B2B. Sequence type FRST/RCUR (RCUR alone is acceptable in Core since 2016), and reference UMR + CI on every collection.
4. Read pain.002 for rejects before settlement and camt.053/054 for returns after. A collection is provisional until the return windows close.
5. Handle R-transactions by reason code: AM04 insufficient funds, AC01 incorrect account, AC04 closed account, AC06 blocked account, AG01 transaction forbidden, MD01 no mandate, MD06 refund requested by the end customer, MD07 debtor deceased, MS02/MS03 unspecified customer/agent reason, SL01 specific service of the debtor agent (blocking), RR01 to RR04 regulatory reasons, FOCR following a cancellation request.
6. A mandate lapses after 36 months without a collection; amendments (new IBAN, new CI after a PSP migration) are signalled in the pain.008 amendment block.

What can go wrong: returns arriving up to 8 weeks later for Core (customer refund) and 13 months for MD01 (unauthorised claim); collections on non-TARGET days silently shifting; debtor bank rejecting B2B for unregistered mandate; the payer's bank applying a per-mandate block.

Fees in Principle

• PayNow. No card-style interchange. Your bank prices FAST/PayNow receipts under its corporate tariff (flat per credit, tiered, or bundled with the account), and a PSP aggregating QR generation and notifications adds its own per-transaction or percentage fee. Refunds cost an outbound transfer fee. Confirm with your bank's tariff sheet and your PSP contract.
• iDEAL. Flat cents per successful transaction, set by the acquirer or PSP; no ad valorem component, which is why it dominates high-ticket Dutch checkout. Refund SCTs are charged separately.
• UPI. Merchant discount rate on UPI P2M has been zero by government policy for most categories since 2020, with wallet (PPI)-funded merchant transactions above a threshold carrying interchange. Aggregators may still charge platform, gateway or settlement fees. Check the current NPCI circulars and RBI guidance before modelling.
• SEPA. SCT and SCT Inst are priced by your bank per transaction, and the Instant Payments Regulation forbids charging more for instant than for regular transfers. SDD has no interbank interchange; you pay a per-collection fee, a channel fee (EBICS or PSP), and return fees on every R-transaction, which can exceed the collection fee several times over. Book returns as a cost line, not as noise.

Model total cost per rail as fee + refund transfer cost + (exception rate × handling minutes × loaded rate) + dispute loss. On this measure SDD Core with a 3 percent return rate is rarely cheaper than iDEAL.

Reconciliation Artefacts

Rail	Primary artefact	Join key	Granularity and timing	Gotchas
PayNow	Bank statement (camt.053, bank CSV or notification API)	Bill number in narrative, amount, date	One line per credit, same day	Narrative truncation; payer name may differ from customer name; no scheme file separate from the bank statement
iDEAL	Acquirer settlement report plus one batched SCT credit on the bank statement	iDEAL transaction ID and purchaseID	Itemised daily; bank credit is the batch total	Fees netted or invoiced separately depending on contract; refunds appear as debits in a later batch
UPI	Acquirer or aggregator settlement file (T+1)	RRN, then UPI transaction ID and tr	Daily net settlement	Refunds and TAT auto-reversals appear as separate lines; raw NPCI reports are not usually exposed to merchants
SEPA SCT	camt.053 or camt.054	RF reference or remittance text	Per credit, end of day or intraday	Inbound EndToEndId is the payer's, not yours; unstructured remittance is free text
SEPA SDD	pain.002 (rejects), camt.053/054 (settlements and returns), PSP collection report	EndToEndId (yours) and UMR	Per collection on D; returns for weeks after	Return debits carry the reason code and a fee line; a batch may settle net of returns

Failure Modes Side by Side

Failure	PayNow	iDEAL	UPI	SEPA
Payer abandons	QR expires; nothing to clean up	Cancelled or Expired status	Intent opened, no callback; expire after your window	SCT: nothing arrives; SDD: n/a
Payment pending or unknown	Rare; bank notification delayed	Open status; poll status endpoint	Common; poll, then rely on T+1 auto-reversal	SDD provisional by design
Duplicate	QR scanned twice	Rare; issuer guarantee is per transaction	Intent launched twice	Payer sends twice; same reference arrives twice
Wrong amount	Editable QR	Not possible	Not possible via intent; possible via manual VPA pay	Common on manual SCT
Reversal after success	None	None	None; fraud via UDIR complaints only	SDD returns and refunds; SCT recall only by request to the bank
Scheme outage	FAST or bank outage; fall back to cards	Issuer outage; show issuer status	Bank or NPCI degradation; retries spike duplicates	TARGET closing days for SCT/SDD

Procedure: Bringing One of These Rails Live

1. Confirm entitlement. Singapore bank account with PayNow Corporate, or a licensed PSP; iDEAL acquiring contract via a PSP; an Indian entity or RBI-authorised payment aggregator for UPI; a euro account with EBICS or PSP access and a Creditor Identifier for SDD.
2. Fix the identifiers. Record the scheme reference, your reference field and its length and charset, and design the transform from your canonical order id.
3. Assess sandbox parity. iDEAL offers an issuer simulator; UPI aggregator sandboxes rarely simulate pending or auto-reversal; SEPA testing runs through your bank's test channel; PayNow testing depends on your bank or PSP. Plan manual test cases for what the sandbox cannot produce.
4. Make server-side status the only truth. Redirect returns and app callbacks trigger a status query; webhooks are idempotent on the scheme reference.
5. Ingest the settlement artefact before launch. The first day's payments must match automatically; a rail you cannot reconcile is not live.
6. Write the runbooks for pending, duplicate, expired and wrong-amount cases, with the refund path for each.
7. Pilot at low volume, review the exception rate and refund latency after two settlement cycles, then open the rail to all traffic.

Worked Example: One Order, Four Rails

{
  "order_id": "ORD-2026-000123456",
  "amount_minor": 12900,
  "currency": "SGD|EUR|INR",
  "rails": {
    "paynow":  { "reference": "ORD2026000123456", "scheme_ref": "FAST20260902123456" },
    "ideal":   { "reference": "ORD-2026-000123456", "scheme_ref": "0050000123456789", "payer_iban": "NL91ABNA0417164300" },
    "upi":     { "reference": "ORD2026000123456", "rrn": "624512345678", "txn_id": "ICI4a1b2c3d4e5f6", "payer_vpa": "payer@okbank" },
    "sepa_sdd":{ "end_to_end_id": "ORD-2026-000123456", "umr": "MND-000778", "creditor_id": "NL98ZZZ123456780000", "seq": "RCUR" }
  }
}

The scheme_ref values are illustrative shapes, not real transactions. Store the payer identifier the rail returns (IBAN, VPA) on the payment record so refunds do not require a support ticket.

Worked Example: UPI Intent Link and PayNow QR Fields

upi://pay?pa=merchant@icici&pn=Example%20Store&am=129.00&cu=INR&tr=ORD2026000123456&tn=Order%20123456&mc=5411

am must carry two decimals, tr must be alphanumeric, and pn and tn must be URL-encoded. Where your acquirer mandates signed intents, the signature parameter is added by their SDK; never build it client-side.

PayNow QR (EMVCo merchant-presented, tag / length / value)
00 02 01              payload format indicator
01 02 12              point of initiation: 12 = dynamic (one-time)
26 .. SG.PAYNOW       00 SG.PAYNOW | 01 proxy type (0 mobile, 2 UEN) | 02 proxy value | 03 editable amount (0 = no) | 04 expiry YYYYMMDD
52 04 0000            merchant category code
53 03 702             currency, ISO 4217 numeric for SGD
54 06 129.00          amount
58 02 SG              country
59 .. Example Store   merchant name
60 .. Singapore       merchant city
62 .. 01 ORD2026000123456   additional data: bill number
63 04 XXXX            CRC-16 over the payload

Set editable amount to 0 and populate expiry for every e-commerce QR; validate your encoder against the current PayNow QR specification from ABS before go-live.

Worked Example: SCT Inst and SDD Rejection Handling

pain.002 status: RJCT, reason AC01  -> IBAN invalid: fix master data, do not retry blindly
pain.002 status: RJCT, reason AM04  -> insufficient funds: retry per your dunning policy, add return fee
camt.054 credit reversal, MD06      -> customer used 8-week refund right: mark order unpaid, contact customer
camt.054 credit reversal, MD01      -> unauthorised claim up to 13 months: investigate mandate evidence

Worked Example: Settlement File Match

-- UPI: settlement line without a matching payment, or with an amount mismatch
select s.rrn, s.amount_minor as settled, p.order_id, p.amount_minor as expected
from settlement_lines s
left join payments p
  on p.rail = 'upi' and p.scheme_ref = s.rrn
where s.settlement_date = :d
  and (p.id is null or p.amount_minor <> s.amount_minor);

Run the same shape per rail with the join key from the artefacts table: bill number for PayNow, iDEAL transaction ID for iDEAL, EndToEndId and UMR for SDD. Anything the query returns is an exception, never a silent adjustment.

Checklist: What a Checkout Needs for Each

PayNow: UEN or VPA registered for PayNow Corporate with your bank; QR generator conforming to SGQR; fixed-amount, expiring QR per order; bank notification feed; refund tool that takes a payer proxy.

iDEAL: Contract with an iDEAL acquirer through your PSP; return URL and webhook; server-side status check; IBAN storage for refunds; issuer list refresh (classic flow) or profile support (new flow).

UPI: Indian entity or RBI-authorised payment aggregator; merchant VPA and MCC; intent link builder with signing if required; QR generator; callback endpoint with idempotent status updates; status polling for pending; refund by RRN; AutoPay mandate management if recurring.

SEPA SCT: IBAN and RF reference generator; camt.053/054 ingestion; unmatched-credit exception queue. SEPA SDD: Creditor Identifier; mandate capture and storage with evidence; UMR generator; pre-notification email; pain.008 generation and bank channel (EBICS or your PSP); pain.002 and R-transaction parsing; dunning and return-fee policy.

Common Mistakes

• Trusting the iDEAL redirect or UPI app return as proof of payment. Only server-side status is proof.
• Refunding a UPI or SCT Inst transaction that is still pending, then seeing the original complete.
• Using an editable-amount PayNow QR for e-commerce.
• Collecting SDD Core without pre-notification and then losing every MD06 dispute on goodwill.
• Putting spaces, slashes or hyphens in identifiers a rail rejects (UPI tr and Pix txid are stricter than SEPA).
• Assuming SEPA fees are zero; SDD returns and bank channel fees are real and should hit the ledger.
• Matching inbound SCTs on EndToEndId, which the payer or their bank sets, instead of on your remittance reference.
• Treating a "Failure" from a rail as a customer problem; check your own configuration (MCC, VPA status, acquirer limits) first.

Limits and When Not to Use This

This is an engineering comparison, not a rulebook. Limits, fees, mandate rules and dispute windows change; check the current versions with ABS and MAS for PayNow, Currence/EPI and DNB for iDEAL, NPCI and RBI for UPI, and the EPC rulebooks for SEPA. Licensing to collect on these rails, especially in India and Singapore, is a regulatory matter for a payments lawyer or compliance officer, and nothing here is legal, tax or regulatory advice. This skill offers no guidance on evading transaction limits, capital controls or sanctions screening on any rail. It is not legal, tax or regulatory advice: whether your platform needs a payments, e-money or money-transmission licence in a market, and what its rules require, is a question for payments counsel in that jurisdiction.