Payments Academy
Local payment methods PAYMENT OPERATIONS STARTED LIVE 01 Local payment methods - Every market has a local payment method ACTIVE 02 UPI virtual payment address - uses a virtual payment address QUEUED 03 Failed payment handling by method - Pix payment that fails is retried QUEUED 04 Local method regulatory requirements - has its own regulatory requirements. QUEUED 05 Local method abstraction layer - Without that layer QUEUED 06 BA practice - Last reviewed 7 November 2026. QUEUED Every market has a local payment method that the product must support, and the method shapes the product. Step 1 of 6 Local payment methods STARTED Local payment methods Every market has a local payment method ACTIVE UPI virtual payment address uses a virtual payment address QUEUED Failed payment handling by method Pix payment that fails is retried immediately QUEUED Local method regulatory requirements has its own regulatory requirements. QUEUED Local method abstraction layer Without that layer QUEUED BA practice Last reviewed 7 November 2026. QUEUED Every market has a local payment method that the product must support, and the method shapes the product.
UPI virtual payment address PAYMENT OPERATIONS IN PROGRESS LIVE 01 Local payment methods - Every market has a local payment method DONE 02 UPI virtual payment address - uses a virtual payment address ACTIVE 03 Failed payment handling by method - Pix payment that fails is retried QUEUED 04 Local method regulatory requirements - has its own regulatory requirements. QUEUED 05 Local method abstraction layer - Without that layer QUEUED 06 BA practice - Last reviewed 7 November 2026. QUEUED UPI uses a virtual payment address, which looks like an email address, Step 2 of 6 UPI virtual payment address IN PROGRESS Local payment methods Every market has a local payment method DONE UPI virtual payment address uses a virtual payment address ACTIVE Failed payment handling by method Pix payment that fails is retried immediately QUEUED Local method regulatory requirements has its own regulatory requirements. QUEUED Local method abstraction layer Without that layer QUEUED BA practice Last reviewed 7 November 2026. QUEUED UPI uses a virtual payment address, which looks like an email address,
Failed payment handling by method PAYMENT OPERATIONS IN PROGRESS LIVE 01 Local payment methods - Every market has a local payment method DONE 02 UPI virtual payment address - uses a virtual payment address DONE 03 Failed payment handling by method - Pix payment that fails is retried ACTIVE 04 Local method regulatory requirements - has its own regulatory requirements. QUEUED 05 Local method abstraction layer - Without that layer QUEUED 06 BA practice - Last reviewed 7 November 2026. QUEUED A Pix payment that fails is retried immediately, while an iDEAL payment that fails is abandoned and the customer starts again. Step 3 of 6 Failed payment handling by method IN PROGRESS Local payment methods Every market has a local payment method DONE UPI virtual payment address uses a virtual payment address DONE Failed payment handling by method Pix payment that fails is retried immediately ACTIVE Local method regulatory requirements has its own regulatory requirements. QUEUED Local method abstraction layer Without that layer QUEUED BA practice Last reviewed 7 November 2026. QUEUED A Pix payment that fails is retried immediately, while an iDEAL payment that fails is abandoned and the customer starts again.
Local method regulatory requirements PAYMENT OPERATIONS IN PROGRESS LIVE 01 Local payment methods - Every market has a local payment method DONE 02 UPI virtual payment address - uses a virtual payment address DONE 03 Failed payment handling by method - Pix payment that fails is retried DONE 04 Local method regulatory requirements - has its own regulatory requirements. ACTIVE 05 Local method abstraction layer - Without that layer QUEUED 06 BA practice - Last reviewed 7 November 2026. QUEUED The local method has its own regulatory requirements. Step 4 of 6 Local method regulatory requirements IN PROGRESS Local payment methods Every market has a local payment method DONE UPI virtual payment address uses a virtual payment address DONE Failed payment handling by method Pix payment that fails is retried immediately DONE Local method regulatory requirements has its own regulatory requirements. ACTIVE Local method abstraction layer Without that layer QUEUED BA practice Last reviewed 7 November 2026. QUEUED The local method has its own regulatory requirements.
Local method abstraction layer PAYMENT OPERATIONS IN PROGRESS LIVE 01 Local payment methods - Every market has a local payment method DONE 02 UPI virtual payment address - uses a virtual payment address DONE 03 Failed payment handling by method - Pix payment that fails is retried DONE 04 Local method regulatory requirements - has its own regulatory requirements. DONE 05 Local method abstraction layer - Without that layer ACTIVE 06 BA practice - Last reviewed 7 November 2026. QUEUED Without that layer, every new method requires changes throughout the product, and the cost of adding a method grows with each one. Step 5 of 6 Local method abstraction layer IN PROGRESS Local payment methods Every market has a local payment method DONE UPI virtual payment address uses a virtual payment address DONE Failed payment handling by method Pix payment that fails is retried immediately DONE Local method regulatory requirements has its own regulatory requirements. DONE Local method abstraction layer Without that layer ACTIVE BA practice Last reviewed 7 November 2026. QUEUED Without that layer, every new method requires changes throughout the product, and the cost of adding a method grows with each one.
BA practice: local method requirements PAYMENT OPERATIONS COMPLETE LIVE 01 Local payment methods - Every market has a local payment method DONE 02 UPI virtual payment address - uses a virtual payment address DONE 03 Failed payment handling by method - Pix payment that fails is retried DONE 04 Local method regulatory requirements - has its own regulatory requirements. DONE 05 Local method abstraction layer - Without that layer DONE 06 BA practice - Last reviewed 7 November 2026. ACTIVE Last reviewed 7 November 2026. Step 6 of 6 BA practice: local method requirements COMPLETE Local payment methods Every market has a local payment method DONE UPI virtual payment address uses a virtual payment address DONE Failed payment handling by method Pix payment that fails is retried immediately DONE Local method regulatory requirements has its own regulatory requirements. DONE Local method abstraction layer Without that layer DONE BA practice Last reviewed 7 November 2026. ACTIVE Last reviewed 7 November 2026.

Key points of this lesson, in order.

0:00 / 4:02 Step 1 of 6

Local payment methods by market: what changes when you cross a border

Scheme onboarding, market expansion, build versus buy, Lesson 4 of 7, Narration 4:02, D13 Payments product and business

SettlementRefund

What you will learn

Your objective. By the end of this lesson, you will be able to explain local payment methods by market: what changes when you cross a border and apply it to a real banking scenario.

Why it matters. For a business analyst, the local method is a requirements package per method.

Chapter objective: Joining a scheme, entering a new market, and deciding whether to build or buy

Key learning points

  • Local payment methods
  • UPI virtual payment address
  • Failed payment handling by method
  • Local method regulatory requirements
  • Local method abstraction layer
  • BA practice: local method requirements

Key terms

Settlement: The final movement of funds between banks to discharge obligations created by cleared payments. Settlement is usually made in central bank money or through correspondent accounts.

Refund: A repayment of funds to a customer after a payment fails, is cancelled or is disputed. In card payments a refund returns money to the cardholder account.

Payment flow diagram showing Local payment methods by market: what changes when you cross a border.

Insights and practice scenarios

Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.

Practise this lesson

Exercise

Apply the concept in this lesson to a real banking scenario.

Use the definition, the example and the key points in this lesson.

  1. What to do. Explain the concept in your own words, give a banking example with an amount, and state what goes wrong if it is misunderstood.

Correct result. A correct answer names the concept accurately, uses a realistic banking example with a concrete amount, and identifies the consequence of getting it wrong.

Why. Understanding is not memorising a definition. It is being able to explain it, apply it, and spot the failure it prevents.

Check your understanding

Practice question

Which of the following best describes local payment methods by market: what changes when you cross a border?

Takeaway and next step

What to remember

Pix uses a key, which can be a phone number, an email, a tax number, or a random key, and the payer enters the key instead of an account number.

Follow a payment through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "Entering a new market: licensing, local rails and the regulatory map".

Transcript and full text

Show transcript

Every market has a local payment method that the product must support, and the method shapes the product. In Brazil, Pix is an instant payment system run by the Central Bank of Brazil, and it is free for individuals and cheap for businesses. A product entering Brazil that does not support Pix will not be used, because every Brazilian expects it. In India, UPI is the dominant method, and a product that does not support UPI is invisible. In the Netherlands, iDEAL is the online payment method, and in Germany, Giropay and Sofort play the same role. The product must support the local method, not just the international one. The local method has its own user experience. Pix uses a key, which can be a phone number, an email, a tax number, or a random key, and the payer enters the key instead of an account number. UPI uses a virtual payment address, which looks like an email address, and the payer enters the address instead of the account details. iDEAL redirects the payer to their own bank's website to authorise the payment. Each of these is a different journey, and the product must implement the journey the local customer expects, not the journey the product already has. The local method has its own settlement model. Pix settles instantly in central bank money, 24 hours a day, 7 days a week. UPI settles instantly through the National Payments Corporation of India. iDEAL settles through the bank's own account, usually the next business day. The product must therefore handle different settlement times, different cut-offs, and different failure modes for each method. A Pix payment that fails is retried immediately, while an iDEAL payment that fails is abandoned and the customer starts again. The local method has its own fraud pattern. Pix fraud is often social engineering, where the victim is tricked into sending money to a fraudster's Pix key, and the Central Bank of Brazil has introduced a special refund mechanism for Pix fraud. UPI fraud is often a fake payment request, where the victim is asked to enter their PIN to receive money and instead sends it. The product must implement the local fraud controls, including the refund mechanism, the transaction limits, and the cooling-off period for a new payee, because the regulator will hold the firm responsible. The local method has its own regulatory requirements. In Brazil the Central Bank requires Pix participants to offer the refund mechanism and to report fraud statistics. In India the Reserve Bank requires UPI participants to support the UPI PIN and to limit the transaction value. In the European Union the Payment Services Directive requires strong customer authentication for electronic payments, which affects how the local method authenticates the payer. The requirements must state the local regulatory obligations for each method, and the product must be tested against them. Supporting multiple local methods is an architecture decision. The product needs a payment method abstraction, a layer that presents a common interface to the rest of the product while hiding the differences between Pix, UPI, iDEAL and the others. Without that layer, every new method requires changes throughout the product, and the cost of adding a method grows with each one. With the layer, adding a method means building one connector and one journey, and the rest of the product does not change. The business analyst must specify the abstraction in the requirements. For a business analyst, the local method is a requirements package per method. Each method gets its own journey, its own settlement model, its own fraud controls, and its own regulatory obligations. The acceptance criteria must include a test where a payment is made with each local method, from initiation to settlement, with the correct user experience and the correct status reporting. Last reviewed 7 November 2026. Further reading: the Central Bank of Brazil Pix regulation; the National Payments Corporation of India UPI procedural guidelines; the European Payments Council work on local payment methods; the World Bank Global Payments Systems Survey.

Every market has a local payment method that the product must support, and the method shapes the product. In Brazil, Pix is an instant payment system run by the Central Bank of Brazil, and it is free for individuals and cheap for businesses. A product entering Brazil that does not support Pix will not be used, because every Brazilian expects it. In India, UPI is the dominant method, and a product that does not support UPI is invisible. In the Netherlands, iDEAL is the online payment method, and in Germany, Giropay and Sofort play the same role. The product must support the local method, not just the international one.

The local method has its own user experience. Pix uses a key, which can be a phone number, an email, a tax number, or a random key, and the payer enters the key instead of an account number. UPI uses a virtual payment address, which looks like an email address, and the payer enters the address instead of the account details. iDEAL redirects the payer to their own bank's website to authorise the payment. Each of these is a different journey, and the product must implement the journey the local customer expects, not the journey the product already has.

The local method has its own settlement model. Pix settles instantly in central bank money, 24 hours a day, 7 days a week. UPI settles instantly through the National Payments Corporation of India. iDEAL settles through the bank's own account, usually the next business day. The product must therefore handle different settlement times, different cut-offs, and different failure modes for each method. A Pix payment that fails is retried immediately, while an iDEAL payment that fails is abandoned and the customer starts again.

The local method has its own fraud pattern. Pix fraud is often social engineering, where the victim is tricked into sending money to a fraudster's Pix key, and the Central Bank of Brazil has introduced a special refund mechanism for Pix fraud. UPI fraud is often a fake payment request, where the victim is asked to enter their PIN to receive money and instead sends it. The product must implement the local fraud controls, including the refund mechanism, the transaction limits, and the cooling-off period for a new payee, because the regulator will hold the firm responsible.

The local method has its own regulatory requirements. In Brazil the Central Bank requires Pix participants to offer the refund mechanism and to report fraud statistics. In India the Reserve Bank requires UPI participants to support the UPI PIN and to limit the transaction value. In the European Union the Payment Services Directive requires strong customer authentication for electronic payments, which affects how the local method authenticates the payer. The requirements must state the local regulatory obligations for each method, and the product must be tested against them.

Supporting multiple local methods is an architecture decision. The product needs a payment method abstraction, a layer that presents a common interface to the rest of the product while hiding the differences between Pix, UPI, iDEAL and the others. Without that layer, every new method requires changes throughout the product, and the cost of adding a method grows with each one. With the layer, adding a method means building one connector and one journey, and the rest of the product does not change. The business analyst must specify the abstraction in the requirements.

For a business analyst, the local method is a requirements package per method. Each method gets its own journey, its own settlement model, its own fraud controls, and its own regulatory obligations. The acceptance criteria must include a test where a payment is made with each local method, from initiation to settlement, with the correct user experience and the correct status reporting. Last reviewed 7 November 2026. Further reading: the Central Bank of Brazil Pix regulation; the National Payments Corporation of India UPI procedural guidelines; the European Payments Council work on local payment methods; the World Bank Global Payments Systems Survey.

Full lesson text (all scenes)

Completing a lesson updates your progress dashboard on the homepage.

Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.