Mobile Payments, Wallets and Account-to-Account Payments

Introduction

Mobile payments have changed the relationship between customers, banks, merchants and payment infrastructures. A payment that once required cash, a cheque, a card terminal or a branch visit may now be initiated through a mobile phone in a few seconds. The visible interface may be a banking application, a digital wallet, a merchant application, a social platform or a super-app; the underlying movement of value may occur through a card network, an instant-payment scheme, a bank transfer, a stored-value ledger or an open-banking interface.

For banking professionals, the key issue is not simply whether a payment is “digital.” It is how the payment is initiated, authenticated, authorised, cleared, settled, funded, recorded and governed. These design choices determine cost, speed, fraud exposure, customer experience, interoperability and the distribution of economic power among banks and technology platforms.

This chapter examines QR payments, digital wallets, super-apps, instant account-to-account transfers, request-to-pay, recurring payments and open-banking payment initiation. It also evaluates adoption, interoperability, platform strategy, risk and governance.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Distinguish mobile payments, wallets, card payments and account-to-account payments.
2. Explain the operation and strategic implications of QR-code payments.
3. Analyse wallet, super-app and platform business models.
4. Evaluate instant payments, request-to-pay and recurring-payment arrangements.
5. Explain open-banking payment initiation and its control requirements.
6. Assess adoption, interoperability, risk, regulation and customer protection.
7. Recommend an appropriate payment-channel architecture for a bank or financial institution.

1. The Payment-Channel Architecture

A payment channel can be analysed through six linked layers:

A mobile device is therefore an access instrument rather than necessarily the payment system itself. A wallet may hold stored value, represent a tokenised card, or provide access to a bank account. These models must not be conflated.

1.1 Important distinctions

A mobile payment is a payment initiated or authenticated using a mobile device. A digital wallet is a software environment that stores payment credentials, value, tokens or instruments and enables transactions. An account-to-account (A2A) payment transfers funds directly between payer and payee accounts, usually without a card network in the transaction path. An instant payment is an account transfer in which funds availability and processing occur within a short, scheme-defined period, often continuously. A QR payment uses a two-dimensional barcode to communicate payment information or initiate a payment instruction.

These categories overlap. For example, a customer may use a mobile wallet to scan a merchant QR code and initiate an instant A2A payment.

2. QR Payments

2.1 Static and dynamic QR codes

A static QR code generally contains reusable information such as a merchant identifier or account reference. The customer enters the amount, creating convenience for low-value transactions but also introducing risks of incorrect entry and payment redirection.

A dynamic QR code is generated for a particular transaction and may contain the amount, invoice reference, expiry time and merchant information. It improves reconciliation and reduces ambiguity, although it requires a system capable of generating and validating codes.

QR codes may be:

• Merchant-presented: the merchant displays the code and the customer scans it.
• Customer-presented: the customer displays a code that the merchant scans.
• Closed-loop: usable only within one provider’s ecosystem.
• Open or interoperable: usable across participating banks or payment providers.

2.2 QR transaction process

A typical merchant-presented QR transaction involves the following stages:

1. The merchant generates or displays a QR code.
2. The customer scans it using a banking or wallet application.
3. The application decodes the payment data and displays payee and amount information.
4. The customer authenticates and confirms the payment.
5. The payer institution applies balance, limit and fraud controls.
6. The payment system routes the instruction to the payee institution.
7. The payee receives confirmation or an irrevocable status according to scheme rules.
8. Reconciliation records are created for the merchant.

The confirmation shown to a merchant should not be treated as proof of settlement unless the system provides a reliable, authenticated confirmation. Screenshots and customer-presented messages are vulnerable to manipulation.

2.3 Benefits and limitations

QR payments require less expensive merchant hardware than conventional card terminals and can support micro-merchants. They are useful for person-to-person transfers, retail, transport, bill payment and government disbursement. However, QR payments depend on a trusted application, network connectivity, customer awareness and accurate merchant identification. Social engineering, fake QR stickers, payment to the wrong beneficiary and weak confirmation processes are significant risks.

Interoperability is especially important. If each bank operates a separate QR format, merchants must display multiple codes and customers must maintain multiple applications. A common technical specification, directory, dispute process and liability model can substantially improve adoption.

3. Digital Wallets and Super-Apps

3.1 Wallet operating models

Wallets can be classified by the asset or credential they represent:

A stored-value wallet is not automatically a bank deposit. Its legal treatment depends on jurisdiction, licensing and safeguarding arrangements. A bank must clearly explain whether customer funds are deposits, safeguarded e-money, prepaid value or merely payment credentials.

3.2 Super-apps

A super-app combines payments with services such as commerce, transport, food delivery, messaging, lending, insurance or identity. Its strategic advantage arises from the interaction of data, distribution and frequent customer engagement. Payments may be offered at low or zero visible cost because they support wider commercial activity.

The same integration creates concerns. A super-app may become a gatekeeper between customers and financial institutions. It may use transaction data for credit assessment or targeted marketing, creating privacy, fairness and competition questions. Banks must decide whether to compete through their own customer interface, participate as a regulated infrastructure provider, or form partnerships while preserving control over risk and customer consent.

3.3 Platform economics and adoption

Payment adoption is influenced by customer value, merchant acceptance, trust, cost, usability and network effects. A simplified network-effect relationship can be expressed as:

where V is perceived ecosystem value; B_c is customer benefit; B_m is merchant benefit; N_c and N_m represent the strength or scale of customer and merchant networks; C represents monetary and non-monetary costs; and R represents perceived risk. This is a conceptual model, not a law of demand. The terms are not necessarily measured in identical monetary units, so it should be used for structured analysis rather than precise forecasting.

Network effects are often indirect: more customers make acceptance more valuable to merchants, while more merchants make the service more valuable to customers. Interoperability can accelerate early adoption by reducing the need to join multiple networks, although it may reduce a platform’s ability to lock in participants.

4. Instant Account-to-Account Payments

Instant A2A payments use accounts held at banks or payment institutions and route instructions through an instant-payment infrastructure. Their major characteristics may include continuous availability, rapid confirmation, irrevocability after a defined point and direct account funding.

4.1 Advantages

For customers, instant A2A payments can provide immediate transfers and lower dependence on cards or cash. For merchants, they may reduce acceptance costs and accelerate access to funds. For banks, they create opportunities in payment initiation, cash-management services and data-enabled products.

4.2 Risks

Speed reduces the time available to detect fraud. An authorised push payment scam may be completed before a bank can intervene. Irrevocability can protect certainty for the recipient but increase customer harm where a payer was deceived. A robust service therefore requires beneficiary verification, transaction limits, behavioural analytics, confirmation screens, recovery procedures and clear allocation of liability.

A payment’s technical speed should also be distinguished from finality. “Instant” may refer to customer-facing confirmation, while legal settlement finality depends on scheme rules and the underlying settlement mechanism.

4.3 Interoperability

Interoperability has technical, commercial and institutional dimensions. Technical interoperability concerns message formats, addressing and APIs. Commercial interoperability concerns pricing and participation. Institutional interoperability concerns shared rules, liability, dispute handling and supervision. A technically connected system may still be commercially unattractive or operationally unsafe if these other dimensions are absent.

5. Request-to-Pay and Recurring Payments

5.1 Request-to-pay

Request-to-pay is a structured request from a payee to a payer, delivered through a payment service. The payer can review the amount, payee, due date and reference before authorising payment. It is not, by itself, a payment; it is an initiation and presentment mechanism.

Applications include utility bills, invoices, rent, school fees, subscriptions and government charges. Compared with direct debit, request-to-pay may give the payer more immediate visibility and control. Compared with manual bank transfers, it can improve reference data and reconciliation.

A sound request-to-pay service should provide:

• authenticated payee identity;
• clear amount and due-date information;
• expiry and cancellation controls;
• protection against repeated or fraudulent requests;
• an audit trail of presentation, acceptance and payment;
• accessibility for customers with limited digital capability.

5.2 Recurring payments

Recurring payments can be implemented through card-on-file arrangements, direct debit mandates, standing orders, wallet authorisations or open-banking payment agreements. They differ in who initiates each transaction and how consent is managed.

A recurring-payment mandate should specify the merchant or payee, frequency, amount or permitted variation, duration, notification method and cancellation process. Variable recurring payments require particular care: customers should be informed of changes, and risk controls should detect unusual increases or unexpected payees.

A standing order is generally a customer instruction to a bank to make payments according to a schedule. A direct debit is generally initiated by the payee under a payer mandate, subject to scheme and regulatory rules. The legal distinctions vary by jurisdiction, so product documentation must not assume that these mechanisms provide identical refund or cancellation rights.

6. Open-Banking Payment Initiation

Open banking allows an authorised third-party provider (TPP), with customer consent, to access account information or initiate a payment through regulated interfaces. Payment initiation can allow a customer to pay a merchant directly from a bank account without manually entering account details or using a card.

6.1 Typical flow

1. The customer selects open-banking payment at checkout.
2. The merchant or payment service provider identifies the customer’s bank.
3. The customer is redirected or connected to the bank’s secure authentication environment.
4. The customer reviews the payee, amount and terms.
5. The bank authenticates the customer and authorises the instruction.
6. The bank sends confirmation and processes the payment under applicable scheme rules.
7. The merchant receives status information and reconciles the transaction.

The consent must be specific, informed, revocable where required and limited to the necessary purpose. Screen scraping, in which a customer gives login credentials to a third party, is materially different from token-based, regulated API access and generally creates greater security and liability concerns.

6.2 Strategic implications

Open-banking payment initiation can reduce card acceptance costs, improve account ownership of the customer relationship and support embedded finance. Its weaknesses may include lower consumer familiarity, inconsistent user experience, variable bank API quality, delayed refunds and fragmented liability arrangements.

Banks should evaluate open-banking participation not merely as compliance. APIs can become distribution channels, enable merchant services and support embedded payment products. At the same time, banks must protect authentication systems, consent records, availability and customer service even when another provider controls the user interface.

7. Security, Fraud and Operational Resilience

Mobile payments combine payment risk with device, application, identity and platform risk. Key threats include phishing, SIM replacement, malware, stolen devices, account takeover, QR substitution, mule accounts, synthetic identity, merchant impersonation and authorised push payment fraud.

Controls should be layered rather than dependent on a single authentication event. Important measures include:

• device binding and secure enrolment;
• strong customer authentication appropriate to risk;
• biometrics used with secure fallback methods;
• transaction signing that displays payee and amount;
• beneficiary verification and name matching;
• velocity, behavioural and network analytics;
• device and session-risk assessment;
• real-time customer alerts;
• cooling-off periods for newly added beneficiaries;
• rapid suspension, recall and complaint processes;
• tested business continuity and disaster recovery.

A useful risk-prioritisation concept is expected loss:

where EL is expected loss, P(L) is the probability of a loss event and I(L) is its financial or social impact. The expression assumes that probability and impact can be estimated on a consistent basis. It is a prioritisation tool, not a complete measure of cyber or conduct risk; low-probability events with systemic consequences may require controls even when expected loss appears modest.

Operational resilience requires attention to dependencies: mobile operating systems, cloud providers, telecommunications networks, identity services, payment switches, fraud engines and third-party APIs. A bank should know which service failures can prevent payment initiation, duplicate messages, create uncertain status or delay reconciliation.

8. Governance, Regulation and Ethics

The regulatory issues surrounding mobile and A2A payments include licensing, safeguarding, settlement, operational resilience, data protection, outsourcing, consumer protection, anti-money-laundering controls and competition. The exact obligations differ across jurisdictions, but sound governance commonly requires:

• transparent pricing and terms;
• clear customer consent and privacy notices;
• accessible complaint and redress channels;
• protection of vulnerable customers;
• strong customer authentication proportionate to risk;
• transaction monitoring and sanctions screening;
• segregation or safeguarding of non-bank customer funds;
• fair treatment when fraud or technical failure occurs;
• auditability of decisions made by automated systems.

Artificial intelligence can support anomaly detection, mule-account identification, merchant risk scoring and customer-service triage. It may also generate false positives, discriminate against particular groups or make decisions that staff cannot explain. Governance should therefore include data-quality controls, model validation, human escalation, performance monitoring, security testing and documentation of material decisions. AI should augment—not eliminate—accountability.

Financial inclusion requires more than smartphone access. Customers may face limited connectivity, disability, low digital literacy, language barriers, lack of formal identification or inability to recover a compromised account. Inclusive design includes low-bandwidth modes, clear language, accessible interfaces, assisted channels and non-digital alternatives for essential payments.

9. Performance and Strategic Evaluation

A bank evaluating a mobile-payment channel should use a balanced scorecard rather than transaction volume alone.

A useful unit-cost measure is:

where C_t is average cost per transaction; C_f is fixed period cost; C_v is variable cost per transaction; Q is transaction volume; and C_r is expected risk-related cost for the period. All cost terms must be measured in the same currency and period. This model excludes revenue and should not be mistaken for profitability. It illustrates why high-volume digital channels can have low unit cost while still producing poor returns if fraud, partner fees or infrastructure costs are neglected.

10. Illustrative Case: Riverside Bank’s Merchant Payment Strategy

Background

Riverside Bank is a mid-sized retail bank in a market where several closed-loop wallets have gained popularity. Small merchants complain about multiple QR stickers and delayed reconciliation. The national payment authority is promoting interoperable instant A2A payments.

Problem

Riverside must decide whether to build a proprietary wallet, join the interoperable QR scheme, offer open-banking payment initiation, or pursue all three. Its technology budget is limited, and fraud losses from social engineering are increasing.

Analysis

A proprietary wallet could improve customer engagement but would require substantial investment in merchant acquisition and would risk low acceptance. Joining the common QR scheme offers immediate reach and reduces fragmentation. Open-banking initiation could support e-commerce merchants but depends on reliable APIs and clear liability rules. A wallet remains useful as a customer interface, provided it can route transactions through interoperable rails rather than creating another closed network.

The bank’s risk analysis identifies four priority exposures: fake merchant QR codes, fraudulent beneficiary additions, API downtime and customer confusion about payment finality. It therefore decides that product adoption must be accompanied by verified merchant profiles, name confirmation, transaction signing, real-time alerts and a customer recovery process.

Approach and solution

Riverside adopts a modular architecture. Its mobile application supports interoperable QR and instant A2A payments. It offers a tokenised wallet for cards and account access but does not represent stored value initially. It exposes regulated payment-initiation APIs through certified TPPs and provides merchants with a reconciliation portal. A fraud engine evaluates device, beneficiary, amount, velocity and behavioural signals. The bank also establishes service-level agreements with the payment switch and API partners.

Outcome

The strategy improves merchant acceptance without forcing customers to use a separate closed-loop wallet. The bank gains payment data and fee opportunities while limiting balance-sheet and safeguarding complexity. However, it must continue investing in fraud controls, customer education and platform resilience. Interoperability creates reach, but it also makes service quality and trust decisive competitive factors.

Learning points

1. A wallet interface does not require a proprietary payment rail.
2. Interoperability can be a strategic asset, not merely a regulatory constraint.
3. Instant payment adoption without fraud and recovery controls can damage trust.
4. Merchant reconciliation and dispute handling are as important as customer-facing design.
5. Platform strategy should account for governance, data and dependency risk.

Best-Practice Design Principles

1. Design around a clear customer problem rather than a technology label.
2. Separate interface, payment rail, funding source and settlement mechanism.
3. Make payee identity, amount and payment status unambiguous.
4. Prefer open, documented and secure interfaces where interoperability is valuable.
5. Treat fraud prevention and recovery as core product features.
6. Record consent, authentication, authorisation and status events for audit.
7. Use risk-based controls that avoid unnecessary exclusion.
8. Test failure states, including timeouts, duplicate messages and uncertain settlement.
9. Make pricing, refund rights and liability understandable.
10. Govern third parties and cloud dependencies as extensions of the bank’s control environment.

Chapter Summary

Mobile payments are a channel category encompassing several underlying payment mechanisms. QR payments offer low-cost acceptance but require trustworthy identification, confirmation and interoperability. Digital wallets may hold value, store tokens or provide access to accounts; their legal and risk characteristics differ. Super-apps combine payments with other services and create powerful network and data effects, but may increase concentration and privacy risks.

Instant A2A payments provide rapid account transfers and can reduce dependence on cards, yet speed and irrevocability intensify fraud and recovery challenges. Request-to-pay improves presentment and reconciliation, while recurring payments require precise mandates, customer notice and cancellation controls. Open-banking payment initiation introduces regulated third parties into the payment journey and makes consent, API security, authentication and liability central concerns.

Successful payment-channel strategy depends on adoption, acceptance, economics, resilience, interoperability and trust. Banks should evaluate the entire architecture—from interface to settlement—and should treat customer protection, inclusion and governance as sources of sustainable competitiveness rather than compliance afterthoughts.

Key Terms

Account-to-account payment: A transfer made directly between payer and payee accounts.

Authorised push payment fraud: Fraud in which a customer is deceived into authorising a payment.

Closed-loop wallet: A wallet usable only within a defined provider ecosystem.

Digital wallet: Software that stores value, credentials, tokens or access to payment instruments.

Dynamic QR code: A QR code generated for a particular transaction and usually containing transaction-specific data.

Instant payment: A payment processed and made available within a short, scheme-defined period, often continuously.

Interoperability: The ability of different payment providers or systems to exchange and process transactions.

Merchant-presented QR: A QR code displayed by the merchant for scanning by the customer.

Open banking: Regulated access to account information or payment functionality through authorised third parties.

Payment initiation service: A service that enables a customer to initiate a payment from a bank account through a third party.

Payment finality: The point at which a payment becomes irrevocable under applicable rules.

Request-to-pay: A structured request from a payee asking a payer to review and authorise a payment.

Recurring payment: A series of payments made under a continuing mandate or scheduled instruction.

Stored-value wallet: A wallet in which value is recorded in a wallet ledger rather than merely represented by a payment credential.

Super-app: A platform integrating payments with multiple commercial or social services.

Strong customer authentication: Authentication using appropriately independent factors or equivalent risk controls.

Tokenisation: Replacement of sensitive payment credentials with a restricted-use token.

Transaction signing: Authentication that binds approval to transaction details such as payee and amount.

Third-party provider: An authorised external provider accessing payment or account services with customer consent.

Review Questions

Short Answer Questions

1. Distinguish a mobile payment from an account-to-account payment.
2. What is the difference between a static and a dynamic QR code?
3. Why is interoperability important for merchant QR acceptance?
4. Explain the purpose of request-to-pay.
5. Identify two risks associated with instant payments.

Long Answer Questions

1. Compare stored-value wallets, tokenised card wallets and pass-through bank wallets.
2. Explain the strategic benefits and risks of super-apps for banks.
3. Describe the operational flow and governance requirements of open-banking payment initiation.
4. Analyse how recurring payments differ from standing orders and direct debits.
5. Discuss how a bank should design a fraud and operational-resilience framework for mobile payments.

Analytical / Application Questions

1. A market contains five incompatible QR schemes. As a banking strategist, recommend a transition path toward interoperability and identify the commercial and governance obstacles.
2. A merchant reports that a customer shows a successful payment screenshot, but the bank’s system shows no completed transaction. Analyse the possible causes and propose controls.
3. Design a balanced scorecard for deciding whether a bank should launch a proprietary wallet or rely on an interoperable instant-payment application.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes an account-to-account payment from a tokenised card-wallet payment?

A. An account-to-account payment transfers directly between accounts, whereas a tokenised card wallet represents a card credential.

B. An account-to-account payment can occur only in cash.

C. A tokenised card wallet never requires authentication.

D. An account-to-account payment cannot be initiated by a mobile device.

Correct Answer: A. An account-to-account payment transfers directly between accounts, whereas a tokenised card wallet represents a card credential.

Question 2

What is the principal advantage of a dynamic QR code over a static QR code?

A. It can be used without any payment application.

B. It can contain transaction-specific details such as amount and invoice reference.

C. It eliminates the need for customer authentication.

D. It guarantees settlement regardless of network availability.

Correct Answer: B. It can contain transaction-specific details such as amount and invoice reference.

Question 3

Which feature most directly supports interoperability among QR payment providers?

A. A separate proprietary format for every bank

B. A common technical specification and shared scheme rules

C. Requiring merchants to display one code per customer

D. Removing beneficiary identification

Correct Answer: B. A common technical specification and shared scheme rules

Question 4

Why can instant payments increase fraud exposure?

A. They always use paper instructions.

B. Their speed may leave less time to detect or stop an authorised fraudulent payment.

C. They cannot use authentication.

D. They are never recorded in bank systems.

Correct Answer: B. Their speed may leave less time to detect or stop an authorised fraudulent payment.

Question 5

Request-to-pay is best described as:

A. An automatic debit that never requires customer consent

B. A structured request that allows the payer to review and authorise a payment

C. A card-tokenisation method

D. A settlement account held by a merchant

Correct Answer: B. A structured request that allows the payer to review and authorise a payment

Question 6

Which control is most relevant to preventing payment to an impersonated beneficiary?

A. Beneficiary verification and name matching

B. Increasing screen brightness

C. Removing transaction alerts

D. Using only static QR codes

Correct Answer: A. Beneficiary verification and name matching

Question 7

In open-banking payment initiation, the customer should normally:

A. Give the third party the bank’s password for unrestricted use

B. Authenticate through a secure bank or regulated interface and review the payment details

C. Authorise every payment by visiting a branch

D. Disable transaction monitoring

Correct Answer: B. Authenticate through a secure bank or regulated interface and review the payment details

Question 8

In the conceptual equation EL = P(L) × I(L), what does I(L) represent?

A. The identity of the customer

B. The impact of a loss event

C. The number of login attempts

D. The interest rate on a loan

Correct Answer: B. The impact of a loss event

Question 9

Which wallet model records customer funds in a wallet ledger?

A. Stored-value wallet

B. Tokenised card wallet only

C. Merchant-presented QR code

D. Payment switch

Correct Answer: A. Stored-value wallet

Question 10

Which is a central governance concern for recurring variable payments?

A. The absence of any payment schedule

B. Clear notice, consent and customer control over changes in amount or frequency

C. Prohibiting all cancellation mechanisms

D. Ensuring that payees cannot be identified

Correct Answer: B. Clear notice, consent and customer control over changes in amount or frequency