Alternative rails checkpoint
Wallets, PSP roles, alternative payment methods and BNPL, open-banking payment initiation, and Request to Pay: can you tell what runs on the card rails, who holds the money, and which model asks versus pulls?
QUESTIONS AS TEXT
Q1. What is the essential difference between a pass-through wallet and a staged wallet?
Answer: A: A pass-through wallet presents an underlying card credential so the payment runs on the card rails; a staged wallet pays the merchant from its own balance and funds itself separately, in two stages.
The dividing line is where the money is and how many stages there are. A pass-through wallet is a presentation layer over a card: it hands over a device token and cryptogram, and the transaction settles on the card rails like any card payment. A staged wallet holds a balance, pays the merchant from it, and funds that balance separately, which changes who the merchant's counterparty is and how data flows for screening and disputes.
Q2. In device tokenisation, what is stored on the customer's phone instead of the real card number?
Answer: A: A device token (a DPAN) bound to that device, used with a one-time cryptogram for each payment.
Device tokenisation replaces the real card number (PAN) with a device primary account number (DPAN) provisioned through the network's token service and stored on the device. Each payment carries a one-time cryptogram proving the token is used on its own device, so a captured DPAN is far less useful to a fraudster and can be revoked without reissuing the physical card.
Q3. A payment gateway and an acquirer are often bundled by one vendor, but they play different roles. What does the gateway do?
Answer: A: It captures payment details at checkout and passes them securely to the acquirer or PSP for authorisation — a connection and translator, not a holder of funds.
A gateway is the technical pipe at the point of payment: it captures details, encrypts and formats the authorisation request, forwards it to the acquirer or PSP, and returns the approve-or-decline answer. It does not hold or settle funds. The confusion is understandable because a single vendor commonly bundles a gateway with acquiring and broader PSP functions under one contract.
Q4. In the payment facilitator (payfac) model, how do small sellers accept cards?
Answer: A: As sub-merchants under one facilitator that holds the acquiring relationship, so each seller does not need its own acquirer contract.
A payment facilitator holds the acquiring relationship and onboards many sellers as sub-merchants beneath it, taking on underwriting, fund aggregation, and much of the risk and compliance in exchange for fast onboarding. Card-network rules govern how sub-merchants are identified and how far a facilitator can aggregate before a seller must be boarded directly, which is why screening and monitoring duties concentrate on the facilitator.
Q5. Why is it more honest to describe buy now, pay later (BNPL) as a lending product than as a payment method?
Answer: A: The provider pays the merchant now and the customer repays later, so the credit decision, repayment risk, and consumer-protection questions all behave like lending.
In BNPL the provider pays the merchant close to full value immediately and the customer repays the provider later, often in interest-free instalments or over a longer interest-bearing plan. That means a credit decision, the customer's repayment risk, and lending-style consumer protections all sit with the provider. Being honest about the framing matters because missed payments and affordability behave like credit, not like a card refund.
Q6. What is an account funding transaction (AFT)?
Answer: A: A card transaction categorised by the network as moving money into an account or wallet, rather than paying for goods — such as a staged-wallet top-up.
An account funding transaction is a card transaction the network categorises as moving funds into an account, wallet, or prepaid balance rather than buying goods or services. It is the funding leg behind a staged-wallet top-up or a load onto a prepaid card. The network flags it so issuers, acquirers, and compliance teams can treat it differently from a purchase, because moving money between accounts carries different risk.
Q7. In an open-banking payment initiation, where do the funds actually move from, and who moves them?
Answer: A: Directly from the payer's own bank account, executed by the payer's bank after it applies strong customer authentication — the initiation provider never holds the funds.
In payment initiation, a licensed third party instructs the customer's own bank — the account servicing provider — to make a payment, on the customer's explicit consent. The bank applies strong customer authentication and then debits the account and executes a normal transfer, usually a SEPA credit transfer. The initiation provider triggers but never holds the money, which is what distinguishes it from a party in the flow of funds.
Q8. Which pair correctly separates the two main open-banking third-party roles?
Answer: A: A PISP initiates payments on the customer's consent; an AISP reads account information but cannot move money.
Open banking separates reading from moving. A payment initiation service provider (PISP) triggers a payment from the customer's account on their consent; an account information service provider (AISP) retrieves balances and transactions but cannot initiate a payment. Both are third-party providers distinct from the account servicing provider (ASPSP) — the customer's bank — which actually debits the account. Keeping the two consents separate is why the roles are named apart.
Q9. What is the difference between redirect and decoupled authentication in open banking?
Answer: A: Redirect hands the customer to their bank's app or page to approve inline; decoupled has them approve in a separate channel, such as a push to the banking app, without a redirect.
Both are strong-customer-authentication patterns; the difference is the journey. Redirect sends the customer to their own bank's app or page to authenticate and approve, then returns them — clean security boundary, visible hand-off. Decoupled prompts the customer out of band, typically a push to their banking app, so there is no inline redirect, which can feel smoother but depends on the app being set up and answered promptly.
Q10. What best describes Request to Pay?
Answer: A: A messaging layer: the payee sends a structured request to pay, the payer accepts, defers, or declines, and if accepted the payer initiates a normal credit transfer to settle.
Request to Pay standardises how a payee asks a payer to pay and how the payer answers — accept, defer, or decline. It is deliberately just a messaging layer: the money still moves by a separate payment the payer initiates after accepting, typically a SEPA credit transfer. In SEPA the request is carried as a pain.013 and the response comes back as a pain.014, keeping the payer in control while giving the payee a clean, reconciled link.
Q11. In SEPA Request to Pay, which messages carry the request and the payer's response?
Answer: A: A pain.013 carries the payee's request; a pain.014 returns the payer's response.
The payee raises the request as a pain.013, and the payer's answer — accept, defer, or decline — returns as a pain.014. These are request-and-response messages only: if the payer accepts, settlement happens through a separate credit transfer, commonly an SCT Inst. Keeping the request messages distinct from the settlement messages is what lets Request to Pay stay a request rather than a pull.
Q12. Why does Request to Pay give the payer more control than a SEPA Direct Debit?
Answer: A: The payer must accept each request before any money moves, whereas a direct debit lets the creditor pull under a mandate the payer gave in advance.
The arrow of initiation is the difference. A direct debit lets the creditor pull funds under a mandate signed once, so the payer does not act per collection. Request to Pay reverses that: each request is an ask the payer must accept, defer, or decline, and no money moves without that choice. Settlement, when it happens, is a normal credit transfer the payer initiates — control up front rather than a refund right after the fact.