1. Card Payment
Overview of Evolutions, Technology & Business
Nugroho Gito
Software Client Architect
IBM Indonesia
ngito@id.ibm.com
2. Agenda
Payment Terminologies
A. Payment Overview
1. Magnetic Stripe
2. Smart Card
3. Contactless Smart Card
4. NFC
5. QR Payment
B. Payment Media Evolution
C. Payment Network
D. QR Payment
E. Payment Gateway
3. Revision History
Purpose of this document is to give general overview of how Payment industry works.
Content of this slide has been collected from various sources, and it will mention the
references.
This is a “Payment 101” slides which consists of 3 payment areas:
1. Card Payment (This document)
2. International Payment (WIP)
3. Domestic Payment (WIP)
Date Version Author Description
2016/03/11 1.0 ngito@id.ibm.com Initial Version
2017/04/28 1.1 ngito@id.ibm.com Restructure quite a lot, add QR payment
7. Card Payment Terminology
No Terminology Description
1 Payment Participants Acquirer, Issuer & Payment Network
2 Acquirer Bank that manage Merchant account and issued EDC, operated by Merchant, where transaction initiated.
3 Issuer Bank that issues Debit/Credit Card, manage customer’s account, and authorize transaction
4 Payment Network Organization as an intermediary that provides transaction routing and connects acquirer and issuer
5 Merchant Business owner that operates EDC and have their funds managed by Acquirer
6 Customer Person who use debit/credit cards to purchase goods/services at merchant, their funds managed by Issuer
7 ISO8583 Messaging protocol that is widely used in Card Payment Network
8. QR Payment Terminology
No Terminology Description
1 QR Quick Response Code
Invented in 1994 by the Japanese company Denso Wave. Its purpose was to track vehicles during manufacturing; it was designed to
allow high-speed component scanning.[3] QR codes are now used in a much broader context, including both commercial tracking
applications and convenience-oriented applications aimed at mobile-phone users (termed mobile tagging). QR codes may be used
to display text to the user, to add a vCard contact to the user's device, to open a Uniform Resource Identifier (URI), or to compose
an email or text message.
2 EMVCo QR QR Payment Standard that standardize information exchange between Merchant & Customer QR App created by EMVCo (Visa,
MasterCard, JCB, American Express, China UnionPay, and Discover)
3 EMVCo QR Tag Predefined set of tags that have specific meaning, followed by a value.
https://www.emvlab.org/emvtags/all/
4 TLV Within data communication protocols, TLV (type-length-value or tag-length-value) is an encoding scheme used for optional
information element in a certain protocol.
The type and length are fixed in size (typically 1-4 bytes), and the value field is of variable size. These fields are used as follows:
Type
A binary code, often simply alphanumeric, which indicates the kind of field that this part of the message represents;
Length
The size of the value field (typically in bytes);
Value
Variable-sized series of bytes which contains data for this part of the message.
5 Issuer App Organization that issues a QR App, and hold the customer funds / wallets
6 Acquirer App Organization that has network of merchants, and hold merchant funds / wallets
9. NPG Terminology
No Terminology Description
1 NPG / GPN National Payment Gateway / Gerbang Pembayaran Nasional
2 Switching
Institution
Has the function and task to domestically process the
payment transaction data for interconnectivity and
interoperability of payment system. For this purpose, all
Switching Institutions are obliged to cooperate with at least two
other Switching Institutions and their cooperation is subject to
specific Standard set by BI.
Organization: Rintis, Artajasa, Jalin, Alto
3 Services
Institution
Tasked to manage services provided to fulfil the needs of retail
payment system industry (“Services”) in NPG
Ecosystem
Organization: PT Penyelesaian Transaksi Elektronik Nasional
4 Standard
Institution
Prepare, develop and manage standardized technical and
operational specifications for the interconnectivity and
interoperability of payment instruments, payment channels,
switching and the overall security of the payment system
(“Standard”), under the guidance and supervision of BI.
Organization: PT Asosiasi Sistem Pembayaran Indonesia
Switching
Standard
Services
11. A.1. Payment Stakeholders
A. Stakeholder
1. Cardholder
2. Merchant
3. Acquirer
4. Payment Networks
5. Issuer
B. Emerging Technology
1. Digital Wallet
2. Digital Currency
3. Near Field Communications
4. QR Payment
https://en.wikipedia.org/wiki/Card_scheme
12. Cardholder
Issuer
Merchant
Acquirer
Card payment
Service / product
Card Payment Network
Setting the rules to applied within
the Network.
Acting as switch and router
between the issuer and acquirer
Interchange Fee
Settlement of funds
Settlement of
funds
Service FeePaymentInvoice
Legend:
Electronic information
Monetary funds
Four-party scheme
13. Reconcile between
Acquirer & Issuer
Settle between Acquirer
& Merchant
Settle between Acquirer
& Issuer
A.2. Payment Formula
Payment
Money
Transfer
Fulfillment
Reconcile +
Settlement
From Customer Account
Authorized by Issuer
Bank
To Merchant Account
Received by Acquirer
Bank
Via Payment Network
Fulfill Goods/Services
From Merchant to
Customer
This is my personal opinion, please kindly confirm with other various sources
14. A.2. Payment Formula (Examples)
Payment Money Transfer Fulfillment
Reconcile + Fund
Settlement
This is my personal experience, please kindly confirm with other various sources
Case 1:
Credit Card Purchase
BNI Visa Cardholder (Issuer)
Purchases
Swarovski (Goods)
swipes at
BCA EDC (Acquirer)
via
Visa Payment Network
Fulfillment
- Merchant deliver goods /
perform services to fulfill
customer’s purchase
Reconcile
- BNI Issuer with Visa
- BCA Acquirer with Visa
Fund Settlement
- BCA Acquirer with BNI Issuer
- BCA Acquirer with Merchant
Case 2:
Debit Card Bill Payment
BCA Debit Cardholder (Issuer)
Pays
PLN (Biller) Electricity Bill
(Services)
Fulfillment
- PLN flags customer bill as paid
Reconcile
- BCA Acquirer with PLN Biller
Fund Settlement
- BCA Acquirer with PLN Biller
Case 3:
Credit Card E-Commerce
via Paypal
BNI Visa Cardholder (Issuer)
purchases
Apple iPad (Goods)
from
Bhinneka (Merchant)
using
Paypal wallet (Acquirer)
Fulfillment
- Bhinneka delivers Apple iPad
to customer using TIKI JNE
Reconcile
- BNI Issuer with Visa
- Bhinneka with Paypal
Fund Settlement
- BNI Issuer with Paypal
- Paypal with Bhinneka
15. A.3. Card Payment Processing Overview
1. Authorization
1. The cardholder presents the merchant with a Visa card for payment.
The merchant point of sale terminal reads the account number and
other data encoded on the card’s magnetic stripe or chip.
2. The merchant terminal transmits the card information and transaction
amount to the acquirer.
3. The acquiring financial institution or its third party processor combines
the transaction information into an authorization request message and
transmits it to Visa.
4. Visa routes the authorization request to the issuer for review. In
certain circumstances, such as when the issuer’s systems are
unavailable, Visa may perform stand-in processing and review and
authorize or deny the transaction.
5. The issuing financial institution or its third party processor returns an
authorization response message, either approving or denying the
transaction to Visa.
6. Visa routes the authorization response to the acquirer.
7. The acquirer transmits the result of the authorization request to the
merchant terminal.
2. Clearing & Settlement
1. Clearing
1. The merchant transmits sales draft information for the
transaction, including account numbers and transaction amounts,
to the acquirer.
2. The acquiring financial institution or its third party processor
formats this information into a clearing message, which it
transmits to Visa.
3. Visa routes the clearing message to the card issuer and calculates
the settlement obligation of the issuer and the amount due to
the acquirer, net of certain applicable fees and charges.
2. Settlement
1. The issuer sends funds to Visa’s designated settlement bank in
the amount of its settlement obligation.
2. The settlement bank, at the direction of Visa, transfers funds due
to the acquirer.
http://financetrain.com/how-credit-card-transaction-processing-works/
17. B.1. Payment Media Evolution
Chip Card EMV
19941969
Magnetic Stripe
2000
Dual Interface
Card
2004
Near Field
Communication
Contactless Smart
Card (RFID)
Stored Value /
Prepaid
Card
1997 2011
QR Payments
18. B.2. Magnetic Stripe
Overview
1. Invented by: IBM Information Records Division – 1969
2. Applications:
1. Banking: Debit, Credit, Prepaid Debit Cards
2. Public Sector: Social Security, Parking, Driving License
3. Other: Passport, Discount, Membership, Gift, Loyalty, Telephone, Hospital
3. Authorization: Online Only
Banking Specific (Payment Cards)
1. Financial Information:
1. Card Information, Stored in card & Card Management System
1. PAN (Primary Account Number – 16/19 digits)
2. Expiry Date
3. CVV (stored in magnetic stripe) – Used for Card Present Transaction
CVV2 (printed at card) – Used for Card Non Present Transaction
2. Account Information
1. Linked to Saving / Checque / Credit Card Account (Unsecured Loan)
2. Information Stored (Plain Text):
1. Track1
2. Track2
3. Track3
3. Standards: ISO/IEC 4909, 7810, 7811, 7812, 7813, 4909, 8583
4. Reference https://en.wikipedia.org/wiki/Magnetic_stripe_card
Magnetic Stripe Card Reader Magnetic Stripe Track1, 2, 3
19. B.2. Magnetic Stripe Examples
Track 1:
%B1234567890123445^PADILLA/L. ^99011200000000000000**XXX******?*
^^^ ^^ ^^ ^ ^ ^ ^^
|||_ Card number ||_ Card holder || | | |_ CVV** ||_ LRC
||_ Format code |_ Field separator || | | |_ End
sentinel
|_ Start sentinel Field separator _|| | |_ Discretionary data
Expiration _| |_ Service code
Track 2:
;1234567890123445=99011200XXXX00000000?*
^^ ^^ ^ ^ ^^
||_ Card number || | |_ Encrypted||_ LRC
|_ Start sentinel|| | PIN*** |_ End sentinel
|| |_ Service code
Field separator _||_ Expiration
http://www.gae.ucm.es/~padilla/extrawork/magexam1.html
Track 3:
;011234567890123445=724724100000000000030300XXXX040400099010=************************==1=0000000000000000?*
^^ ^ ^^ ^ ^ ^ ^ ^ ^^ ^ ^ ^^ ^^^^^ ^^
|| | || | |_ Currency | | | || | | ||_ First subsidiary |||||_ Additional ||
|| | || | exponent | | | || | | | account number (FSAN)|||| data ||
|| |_ Card number || |_ Currency | | | || | | |_ Field separator ||||_ Field ||_ LRC
||_ Format code || (Peseta) | | | || | |_ Expiration ||| separator |_ End sentinel
|_ Start sentinel ||_ Country (Spain) | | | || |_ FSAN service restriction |||_ Relay marker
|_ Field separator | | | ||_ PAN service restriction ||_ Field separator
Cycle length _| | | |_ Interchange control |_ Field separator
Retry count _| |_ Encrypted PIN***
20. B.2. Smart Cards
Overview
1. Invented by: Roland Moreno, 1974
2. Applications:
1. Banking: Debit, Credit, Prepaid Cards
2. Telco: SIM Card
3. Others: e-Passport, Transport Card, Healthcare, Enterprise Identity, Parking
3. Authorization: Online & Offline
Banking Specific (Payment Cards)
1. Financial Information:
1. Card Information, stored in card & Card Management System
1. PAN (Primary Account Number – 16/19 digits)
2. Expiry Date
3. CVV/CVV2
2. Account Information
1. Linked to Saving / Checque / Credit Card Account (Unsecured Loan)
2. Information Stored:
1. Track1
2. Track2
3. Track3
3. Standards: EMV
4. Reference http://www.smartcardalliance.org/, https://en.wikipedia.org/wiki/Smart_card
Contact Smart Card
Contactless Smart Card
21. B.2. Smart Cards
http://home.cc.umanitoba.ca/~kinsner/whatsnew/tutorials/tu1999/smcards.html
http://arxiv.org/ftp/arxiv/papers/1507/1507.06427.pdf
http://www.scardsoft.com/documents/COS/heng_guo.pdf
http://www.slideshare.net/anshus/technical-overview-of-java-card
Smart Card
Communication Between Reader vs Card
Smart Card - Software Architecture
Smart Card - File System Architecture
Smart Card - Software Architecture
CommandAPDU
1. A class type (CLA). It identifiesthe class of the instruction,for example if the instructionis ISO conformant or
proprietary, or if it is using secure messaging.
2. An instructionbyte (INS). It determines the specificcommand.
3. Two parameter bytes P1 and P2. These are used to pass command specificparameters to the command.
4. A length byte Lc (“lengthcommand”). It specifiesthe length of the optionaldata sent to the card with this
APDU.
5. Optional data. It can be used to send the actual data to the card for processing.
6. A length byte Le (“lengthexpected”). It specifiesthe expected length of the data returned in the subsequent
response APDU. If Le is 0x00, the host side expects the card to send all data availablein response to this
command.
Response APDU Format
1. Optional data.
2. Two status word bytes SW1 and SW2. They contain the status information as defined in ISO 7816-4.
Application Protocol Data Units
Smart Card OS
22. B.2. Smart Cards
Smart cards offer a number of features that can be used to provide or
enhance privacy protection in systems. The following is a brief
description of some of these features and how they can be used to
protect privacy.
▪ Authentication
▪ Secure data storage
▪ Encryption
▪ Strong device security
▪ Secure communications
▪ Biometrics
▪ Personal device
23. B.3. Contactless Smart Card
▪ The contactless smart card contains an antenna embedded within the
plastic body of the card.
▪ When the card is brought into the electromagnetic field of the reader,
the chip in the card is powered on.
▪ Once the chip is powered on, a wireless communication protocol is
initiated and established between the card and the reader for data
transfer.
▪ The following four functions describe at a high level the sequence of
events that happen when a contactless smart card is brought near a card
reader:
▪ Energy transfer to the card for powering the integrated circuit (chip)
▪ Clock signal transfer
▪ Data transfer to the contactless smart card
▪ Data transfer from the contactless smart card
▪ Hence, once the card is brought within range of an electromagnetic
field of the required frequency (13.56 MHz), the card will be powered
up, ready to communicate with the reader.
27. Cardholder
Issuer
Merchant
Acquirer
Card payment
Service / product
Card Payment Network
Setting the rules to applied within
the Network.
Acting as switch and router
between the issuer and acquirer
Interchange Fee
Settlement of funds
Settlement of
funds
Service FeePaymentInvoice
Legend:
Electronic information
Monetary funds
Four-party scheme
28. Card Payment Network
N
o
Brand Standard Maintainer
Organization
Operator
Organization
Origin
Country
Transaction
Scope
Chip Card
Standard
Contactless
Standard
Interbank
Fund Transfer
QR Code
Standard
1 UnionPay China UnionPay (CUP)
(Zhōngguó Yínlián),
Est 2002
China UnionPay China Domestic
Intl’ supported
via other
payment
network
PBOC
2.0/3.0
QuickPass CUP
(ISO8583
Based)
Alipay
WeChat Pay
UnionPay QR
Code
2 RuPay National Payments
Corporation of India
(NPCI), Est. 2008
National
Financial Switch
(NFS), Est. 2004
India Domestic
Intl’ supported
via other
payment
network
RuPay EMV RuPay
Contactless
UPI & IMPS
(XML API
front end
with ISO8583
back end)
Bharat QR
3 GPN Asosiasi Sistem
Pembayaran
Indonesia (ASPI)
Rintis, Artajasa,
Jalin, Alto
(RAJA), Est. 2017
Indonesia Domestic NSICCS UNIK GPN
(ISO8583
Based)
N/A
4 Visa Visa Inc, Est. 1958 Visa Inc USA International EMV payWave N/A mVISA
(EMVCo)
5 MasterCard MasterCard Inc, Est.
1966
MasterCard Inc USA International EMV Paypass N/A Masterpass
QR (EMVCo)
PS: Other Card Payment Network are not listed in this table are American Express, Discover, JCB, Diners Club, BC Card
29. How Payment Networks Make Money
1. Network participation fees
Issuing banks (the cardholder's bank) pay a service fee that is a percentage of the payments value processed on cards (debit,
credit, or prepaid) issued on that network.
Acquiring banks (the merchants bank) also pay a service fee that is a percentage of the payments value processed through that
network.
2. Data processing fees
Issuing and acquiring banks also pay small fees for each transaction that is authorized or settled on its network. These fee are not
related to the value of the transaction.
3. International transaction fees
Revenue from currency conversion and other international transaction fees.
4. Other
Revenue from operating rewards programs, concierge services, marketing promotions for certain merchants, and other programs
that issuing banks offer to cardholders.
http://www.gae.ucm.es/~padilla/extrawork/magexam1.html
30. How Visa / MasterCard Make Money
http://www.gae.ucm.es/~padilla/extrawork/magexam1.html
31. General Card Payment Transaction Type
Terminal Principal Acquirer Principal Issuer IssuerAcquirerMerchant Customer
On Us
Off Us 1
Off Us 2
Transaction Type
1. On Us: Acquirer = Issuer
2. Off Us 1: Principal Acquirer <> Principal Issuer
3. Off Us 2: Principal Acquirer = Principal Issuer
32. General Card Transaction Flow
Rintis
Jalin
Alto
ArtajasaIssuer
+ Merchant Account
+ Merchant QR App
Issuer
+ Customer Account
+ Customer QR App
Acquirer
+ Merchant Account
+ Merchant QR App
Issuer
+ Customer Account
+ Customer QR App
Acquirer
+ Merchant Account
+ Merchant QR App
On Us
Transaction Type
1. On Us: Acquirer = Issuer
2. Off Us 1: Acquirer <> Issuer, Principal Acquirer <> Principal Issuer
3. Off Us 2: Acquirer <> Issuer, Principal Acquirer = Principal Issuer
Messaging Standard: ISO8583
33. Card Payment Message Standard – ISO8583
▪ https://en.wikipedia.org/wiki/ISO_8583
▪ ISO 8583 is an international standard for financial transaction card originated
interchange messaging. It is the International Organization for Standardization standard
for systems that exchange electronic transactions initiated by cardholders using
payment cards.
▪ ISO 8583 defines a message format and a communication flow so that different systems
can exchange these transaction requests and responses. The vast majority of
transactions made when a customer uses a card to make a payment in a store (EFTPOS)
use ISO 8583 at some point in the communication chain, as do transactions made at
ATMs. In particular, both the MasterCard and Visa networks base their authorization
communications on the ISO 8583 standard, as do many other institutions and networks.
34. Card Payment Message Structure – Message Type
Message
Type
Primary
Bitmap
Secondary
Bitmap
1-64 Data Elements 65-128 Data Elements
Code Meaning Usage
x0xx Reserved by ISO
x1xx Authorization message
Determine if funds are available, get an approval but do not post to account for
reconciliation. Dual message system (DMS), awaits file exchange for posting to the
account.
x2xx Financial messages
Determine if funds are available, get an approval and post directly to the account.
Single message system (SMS), no file exchange after this.
x3xx File actions message Used for hot-card, TMS and other exchanges
x4xx Reversal and chargeback messages
Reversal (x4x0 or x4x1): Reverses the action of a previous authorization.
Chargeback (x4x2 or x4x3): Charges back a previously cleared financial message.
x5xx Reconciliation message Transmits settlement information message.
x6xx Administrative message
Transmits administrative advice. Often used for failure messages (e.g. message reject
or failure to apply).
x7xx Fee collection messages
x8xx Network management message Used for secure key exchange, logon, echo test and other network functions.
x9xx Reserved by ISO
35. Card Payment Message Structure - Bitmaps
▪ In ISO 8583, a bitmap is a field or subfield within a message, which indicates whether other data elements or data element
subfields are present elsewhere in the message.
▪ Given a bitmap value of 22 10 00 11 02 C0 48 04,
0x22 = 0010 0010 (counting from the left, the third and seventh bits are 1, indicating that fields 3 and 7 are present)
0x10 = 0001 0000 (the first bit corresponds to field 9, so the fourth bit here indicates field 12 is present)
0x00 = 0000 0000 (no fields present)
0x11 = 0001 0001 (fields 28 and 32 are present)
0x02 = 0000 0010 (field 39 is present)
0xC0 = 1100 0000 (fields 41 and 42 are present)
0x48 = 0100 1000 (fields 50 and 53 are present)
0x04 = 0000 0100 (field 62 is present)
Message
Type
Primary
Bitmap
Secondary
Bitmap
1-64 Data Elements 65-128 Data Elements
Therefore, the given bitmap defines the
following fields present in the message:
3, 7, 12, 28, 32, 39, 41, 42, 50, 53, 62
36. Card Payment Message Structure – Data Elements
▪ Data elements are the individual fields carrying the transaction information. There are up to 128 data elements specified
in the original ISO 8583:1987 standard, and up to 192 data elements in later releases. The 1993 revision added new
definitions, deleted some, while leaving the message format itself unchanged.
Message
Type
Primary
Bitmap
Secondary
Bitmap
1-64 Data Elements 65-128 Data Elements
38. QR Code Technology Evolution
Country/Org 2011 2016 2017 Interoperability
China AliPay
WeChat Pay
UnionPay PBOC
Regulating QR
Payment
No national standard and interoperability
India NPCI, MasterCard, Visa
creates National QR
Standard – Bharat QR
PayTM,
Retail Bank
Guaranteed via Bharat QR Standard
Indonesia DIMO Pay
Gojek QR
PayPro
OVO
No national standard and interoperability
EMV EMVCo QR EMVCo QR is loosely regulated standard and
provides general transaction flow, basic data
types, data elements, However detail
implementation will vary between EMVCo
implementation
39. EMVCo QR Presentation Mode
EMVCo QR
Merchant
Presented
Static QR Merchant Info
Dynamic QR
Merchant Info +
Amount
Consumer
Presented
Dynamic QR
Merchant Info +
Amount
Merchant Presented Transaction Detail
Merchant Information Transaction Value Additional Objects
Merchant Account Information
Merchant Category Code
Country Code
Merchant Name
Merchant City
Postal Code
Merchant Information-Alternate
Language
Transaction Amount
Transaction Currency
Tip or Convenience Information
Bill Number
Mobile Number
Store Label
Loyalty Number
Reference Label
Customer Label
Terminal Label
Purpose of Transaction
40. QR Code Payment Architecture
The following describes the high-level functionality of various components of the QR Code processing architecture on the consumer device:
Mobile application/wallet—A consumer-facing user interface (UI) application provided by the issuer, merchant, or a third-party and provisioned to the consumer’s mobile
device. It includes the functionality to encode the payment credentials based on this specification, and then displays the resulting QR Code.
If supported by the mobile application/wallet, the QR Code may also contain other consumer opt-in data, for example, for supporting additional services – these functionalities
are not described in this specification.
The mobile application is responsible for providing a UI that will facilitate card application selection, perform any required CDCVM processing and rendering of the
corresponding QR Code. Figure 2.2 illustrates the process for the consumer.
QR Code Payload—The payload, consisting of payment token credentials and other data based on this specification, converted to base64 and encoded in a QR Code.
EMVCo-Consumer-Presented-QR-Specification-v1.pdf
41. Merchant Presented Transaction Flow
EMVCo-Merchant-Presented-QR-Specification-v1_0.pdf
[1] Merchant generates and displays QR Code based on merchant details.
[2] Consumer scans QR Code using a mobile application to initiate the transaction, with CDCVM if required.
[3] Mobile application sends the transaction initiation request to the Network.
[4] The Network processes the transaction and informs the Merchant and the Consumer of the transaction outcome.
42. QR Code Payment Standards
1. EMVCo
Loosely regulated standard, strict adherence is not required, white
label friendly
2. mVISA
Highly regulated standard, strict adherence, copyrighted standard
3. Masterpass QR
Highly regulated standard, strict adherence, copyrighted standard
43. EMVCo QR Code Payload
"00020101021229300012D156000000000510A93FO3230Q31280012D156000000010
30812345678520441115802CN5914BEST
TRANSPORT6007BEIJING64200002ZH0104最佳运输0202北京
540523.7253031565502016233030412340603***0708A60086670902ME91320016A01
12233449988770708123456786304A13A"
EMVCo Encoded Information
EMVCo QR Code
EMV QR Code Payload Data Objects
EMV QR Code
46. National QR Standard Challenges
1. Standardization
1. Merchant Registry,
2. Acquirer Registry,
3. QR Content
2. Interoperability between Financial Institution (Bank & Non Bank)
1. Solve One Merchant with Multi Acquirer Problem
2. Reconciliation & Settlement
3. Tap Wet Market Merchant
1. Tap millions of people unbankable segment
2. Create Everyone to Everyone Economy – Everyone can be a merchant and can be a customer
48. How to access to wider payment network ecosystem
Build your own Payment Network Connector
vs
Connect to Payment Gateway
Certify & Secure
Acquirer
Issuer
Merchant
Customer
49. Payment Gateway Options
▪ TMoney from Telkom
▪ Payment Gateway for Financial Institution (Bank & Non Bank)
52. USER APPLICATION PROFILE
QR CODE
MICOINVESMENT
MICROINSURANCE
eTRANSPORTASI
LAYANAN PPOB
USER EMONEY
TYPE USER
AGEN CICO COBRANDING
QREN
eRETRIBUSI
ePAJAK
eSAMSAT
ePUSKESMASIN APP
54. Blockchain
▪ It's a shared ledger for recording the
history of transactions – that cannot
be altered.
▪ Blockchain for dummies
https://www-
01.ibm.com/common/ssi/cgi-
bin/ssialias?htmlfid=XIM12354USE
N
▪ Blockchain 101
https://www-
01.ibm.com/common/ssi/cgi-
bin/ssialias?htmlfid=45015045USEN
&