Pay with DuitNow - Malaysian QR payment

Overview

Adoption of new technology, innovation and digitization, the payment ecosystem has forced financial institutions to provide cost-effective, faster, and more convenient services to improve customer experience. 

Payments Network Malaysia (PayNet), The national payments network introduces ‘DuitNow’ QR payment, under Malaysia’s Real-Time Payments Platform (RPP) to start building the foundation of a digital payment ecosystem in Malaysia.

Further to promote cashless real-time payment and encourage the use of digital fund transfer, RPP emphasizes the progressive introduction of multiple new payment products, for multiple payment purposes. Besides QR Payments, Request-to-Pay, e-Mandates, and Real-Time Debit are also launched and expected to transform the payments landscape in Malaysia. However, this document is restricted to ‘DuitNow’ QR service and will cover other services in the future.

What is “DuitNow” QR service?

‘DuitNow’ QR is an overlay service for Real-Time Retail Payments Platform (RPP) Participants. This Convenient, efficient and secured instant credit transfer service, enables the customer to scan a QR code to pay a merchant or to another person and  also customer is capable to receive funds by presenting their own DuitNow QR for scanning. Consumers can make payments from participating Banks or e-wallets mobile applications up to RM 50,000 per transaction and businesses may pay up to RM 10,000,000 per transaction at banks. The limit varies depending on the bank and eMoney providers will have lower limits.
DuitNow QR is Malaysia’s National Standard Quick Response (QR) which was established by PayNet under the Bank Negara Malaysia (BNM), Interoperable Credit Transfer Framework (ICTF).

How does it work? 

PayNet has onboarded banks and eWallet providers to enable customers to initiate payment by using the mobile app of their choice. Customers can download the Issuer bank or service provider’s mobile app on their mobile. The application is capable to scan merchant QR codes and initiate payment. QR code implementation follows the ISO 20022 messaging standard for core payment processing and communication in the financial ecosystem.

‘DuitNow’ QR business scenarios

The QR code can be presented by a Merchant or other user in Peer to Peer payment. 
To elaborate the business flow, consider a merchant presented QR Code payment, which enables the customer to make payment for their purchases. The customer scan ‘DuitNow’ QR code of the merchant, key all the required information and submit the request. On confirmation of the payment, the Credit transfer request directs the issuer bank that holds the debtor account and funds will be automatically debited from the Customer (Debtor) account. Bank then sends the credit transfer request to Creditor bank routing via PayNet. Post successful verification in Creditor bank, the funds will be credited instantly to the Merchant (Creditor) account. 

Model layout with simple steps in ‘DuitNow’ QR payment explained for below scenarios:

• Point-of-sales (POS) payments to Merchants
• Person-to-person (P2P) payments

Inquiry flow:

1. Customer scans a merchant’s QR code via the Mobile application and initiates a QR Payment request.
2. OFI receives the QR Account Enquiry Request (pacs.008) channel.
3. OFI validates the received pacs.008.
4. On successful processing, OFI sends the QR Account Enquiry Request (pacs.008) to PayNet.
5. On receiving pacs.008, PayNet performs validation of the transaction.
6. On successful processing, PayNet sends the QR Account Enquiry Request (pacs.008) to RFI.
7. RFI receives the QR Account Enquiry Request (pacs.008) from PayNet.
8. RFI performs validation on received pacs.008 and performs Account inquiry
9. On successful Account enquiry, RFI sends the QR Account Enquiry positive response (pacs.002) back to ‘PayNet’ with 
10. PayNet will validate the received positive response notification (pacs.002) and send to OFI bank.
11. OFI receives the response notification (pacs.002).
12. OFI validates the received pacs.002 and reconciled with original pacs.008
13. On successful processing of all the above checks, OFI sends back the response notification (pacs.002) to initiating Channel.

Credit Transfer flow:

1. Once Account Enquiry is completed then, the Customer is asked to follow a few details like 
2. Verify the merchant’s name (displayed on screen)
3. Enter Payment amount
4. Keep any other details like promo code or purpose etc.
5. Customer confirms the details in the mobile application.
6. Then OFI validates all the payment information and performs Debit Posting (Debit the customer account)
7. On successful Debit posting, OFI sends the QR Credit Transfer Request (pacs.008) to PayNet.
8. Once PayNet receives pacs.008 validates the message and sends it to RFI.
9. RFI receives the QR Credit Transfer Request (pacs.008) from PayNet.
10. RFI performs required validations and perform Credit Posting (Credit customer)
11. RFI generates the QR Credit Transfer Response (pacs.002) back to PayNet.
12. On successful credit posting, RFI may notify Merchant on successful QR Payment status via camt.054 (debit credit notification).
13. PayNet validates and sends the QR Credit Transfer Response (pacs.002) to OFI.
14. OFI receives the QR Request Notification (pacs.002).
15. OFI performs validation of the received pacs.002 and reconciles with received pacs.008
16. Post successful processing of pacs.002, OFI submits the QR Notification message (pacs.002) to Initiating Channel.

Message types for Merchant presented QR:

The Merchant Presented QR Payment solution is based on the rules and constraints specified in the PayNet RPP Specifications and on the UNIFI (ISO20022) Payments as well as Industry Standard Messages for Credit Transfers and network and system notification messages respectively. Specific messages and unique transaction types signify different services.

QR Code and QR ID

QR Code

A Quick Response Code is a popular type of two-dimensional barcode. This encrypted data is used in payment processing and can store around 5k alphanumeric characters. However, all QR codes generated should comply with PayNet. To read the QR Code, customers should use a scanning application on their smartphone.

Characteristics of QR Code

Types of QR codes used:

Dynamic QR:  

A QR Code that is generated by a Merchant or Recipient for every new transaction.

A Dynamic QR code has a short URL that can be automatically redirected at any time to any site.

Due to the above points metrics like location, used device type etc can be tracked.

Static QR:

QR code has fixed information encoded into the code itself. Data cannot be changed with this QR code.

Scan performance cannot be tracked, limiting scalability.

QR Identifier or QR ID

QR Identifier or QR ID: An alphanumeric code uniquely identifying either a merchant or recipient for the purpose of routing proceeds to the designated merchants or recipient’s Account.

Pay with flexibility – Request to Pay

 

Overview:

Globally financial institutions are innovating and improving their capability to address evolving consumer expectations, razor-thin margins, and increased competition. With the continued adoption of real-time payment schemes across the globe, a set of overlay services are also being developed in parallel, to leverage the low-value instant settlement capabilities provided by the real-time schemes. An overlay service that is gaining a lot of ground is Request to Pay. The service not only enables businesses to manage cashflows more efficiently but also enables payers to have more control over their payment obligations.

Current Pain Points:

• Cash flow management: Some businesses accept partial payments to have greater control over their cash flows. However, in many cases, businesses do not have proper systematic architecture and enabling processes to receive partial funds, reconcile against underlying unique transactions and track the next payment due date details, etc.
• Optimization of working capital: Often in credit card payments, after authorization of payment by the payment provider, transactions take several days to process and settle. Also, charges associated with the processing of transactions are high, which can end up costing millions each year and delaying the final settlement for the merchant.
• Direct debit payments: Used typically for recurring payments like household bills, subscriptions, memberships, charitable donations, etc. Organizations debit the customer account on an agreed date. However, the service generally takes more than two to three working days to process the payments.

What is the Request to Pay?

Request to Pay can be defined as allowing a Payee (or creditor) to claim an amount of payment from a Payer (the debtor) for a specific transaction. Request to Pay is an enhanced messaging service that can facilitate real-time payments by supplementing the existing payments infrastructure to provide more flexibility to businesses and consumers.

How does it work?

Request to Pay acts as an overlay service that provides the ability for consumers or businesses (acting as a payee) to send a payment request to consumers or businesses (acting as a payer).

The payer can access the payment request details including reference number, amount, and due date, and act on the request, including choices to make the full or partial payments, and choose a payment date (if allowed).

Additionally, the service can be enhanced to have features such as

Status report: On acceptance or refusal by the payer, the status would be sent back to the payee via the payee’s payment service provider.

Choice of Payment Method: Making the requested payment via an instant payment scheme might be the most efficient method. However, in some instances, the payment may need to be paid via other payment methods.

With the objective of a real-time and payment scheme agnostic process, Request to Pay can be used to supplement the existing payment methods to provide more control and flexibility to both corporate and retail customers.

Hence this versatile overlay service has the potential to improve service levels in many different contexts like

• Customer-to-Business (C2B)
• Business-to-Customer (B2C)
• Business-to-Business (B2B)
• Person-to-Person (P2P)
• Government-to-Customer (G2C)
• Government-to-Business (G2B)
• e-invoicing
• online commerce

Request to Pay business scenarios

The scope of the Request to Pay standard framework can support a range of payment scenarios, which can cover generic, region, scheme, or business-specific use cases. A few of the scenarios are illustrated below:

A Payer can ‘Accept’ or ‘Decline’ the Request to Pay instruction.

As part of acceptance, the payer can pay immediately or on a future date, if the payee allows.

For both the above payment options, the payer would have the choice to choose a specific payment scheme to initiate the payment, such as low-value ACH, high-value wires, or Instant payment.

Additionally, the payee would be allowed to modify the amount indicated in the Request to Pay instruction.

Payer acceptance or refusal can be transmitted to the Payee via a status report message.

Logical business models

Request to Pay functionality can be achieved by multiple frameworks and established models. The models illustrated below provide a view of the actors involved and the overall ecosystem.

o  Banks or PSPs are connected to the national clearing system.

Illustration of Request to Pay regulated by a clearing scheme.

o  Banks are publishing standardized open banking APIs (application programming interfaces) which can be accessed by fintech use.

Illustration of Request to Pay initiated from Open Banking API.

Standard messages for Request to Pay

Most of the payment schemes consider standard ISO20022 XML format to build Request to Pay framework more or less with same message type including some variations.

• Request to payment to the payer: pain.013 (Creditor Payment Activation Request)
• Response to Request for payment: pain.014 (Creditor Payment Activation Request Status Report)

Applications impacted

Implementation of Request to pay may impact several banking applications as below.

• Core banking system
• Mobile/Web-based application
• Payment processing application
• Sanction/AML/Risk application
• Report/Advices application

Countries adopted R2P

Request to Pay overlay services has been adopted by several real-time payment schemes across the world. For Example, UPI/IMPS (India), TCH RTP (US), SCT Inst (EU), Faster Payments (UK), NPP (Australia), and FAST (Singapore) to name a few.

Additionally, SWIFT gpi (SWIFT Global Payment Initiative), which ensures that globally cross-border payments meet the industry’s expectation with respect to speed, traceability, and transparency, also support R2P implementation.

Benefits

In general, Request to Pay helps improve transparency, improve controls around payment execution and enable smoother end-to-end processing and reconciliation.

The speed, security, and convenience of Request to Pay is expected to provide real value to consumers, and businesses, specifically small and medium-sized enterprises.

Receive authorization from Biller and pay the bill revised future date.

Receive authorization from Biller and pay the bill revised future date.

Explain the problem and request Biller for additional days to pay the bill.

Bill payment is pending due to their busy life or insufficient funds.

Consumer

Allow donating a later full, or partial amount as per the donor’s convenience

Lack of flexibility for recurring or partial payments for donors to donate to Charity.

Non-profit organization

The flexibility of payment with real-time status updates keeps up the connection with donors.

Small Business

Due to delays in payments cash flow challenges and follow-ups with vendors.

Request to Pay can help to build communication between the parties.

Flexibility to pay bills upfront in full or in installments and track those payments in real-time.

Large Business

Payment requests and transactions contain customer reference and remittance information.

Reconciliation of High-value payments is expensive and often takes more time.

Simple, easy, cost-effective, and time-saving reconciliation process.