NAPASMerchantIntegrationSpecification 2.2
NAPASMerchantIntegrationSpecification 2.2
Version 2.2
Hanoi 06-2016
Based on this, merchant can do cost analysis, what type of transaction supported.
NAPAS Payment Gateway designed and followed all international financial standards;
provide monitor function to control transaction and user in system.
Glossary Description
Payment Gateway solution provided by
NAPAS Payment Gateway
NAPAS
Web site where customer can access to
Merchant shopping cart select, order product or service before
going to do payment.
System which manage customer debit
card account and support processing
Bank system
fund transfer amount from customer card
account to merchant account
Secure Socket layer, encryption protocol
SSL
for web connection
One time password generated by bank
system and sent to customer mobile
OTP
under SMS, customer will open SMS and
get OTP code
Joint Stock Foreign Trade Bank of
VCB
Vietnam
In this diagram, we can see that NAPAS will be the middle to communicate with all
merchant integrated, and there are some connections as list below:
- Customer-Merchant: customer access merchant website through web browser to
initial product/service selection for order.
- Merchant-NAPAS: merchant web site after integrate will send payment request to
NAPAS through URL redirect with parameters appended. This also includes redirect
transaction result back from NAPAS to merchant web site and display for customer.
- NAPAS to Bank (Issuer bank): this connection helps NAPAS to communicate with
Bank system for payment order processing.
- Bank to OTP System: when customer required to enter OTP, this connection will
help to request OTP server to generate OTP code for each customer when transact.
- OTP System to Mobile network: when OTP generated, this unique code will be
transfer to customer hand phone through mobile network. Then customer can
receive and enter to OTP authorization web page.
- Vietcombank: as settlement bank for merchant.
i. Transaction flow
Merchant check the validity of customer order then send payment request to NAPAS
to process transaction.
NAPAS will send card info to Bank host to check card and account in Bank system.
Bank host will require customer double check payment amount, term and condition
displayed on screen when do online payment to accept payment.
Bank host will check the valid of card account, balance, limit. If all conditions are
passed, Issuer Bank will generate and send OTP to the customer over SMS gateway
(SMS format and gateway number also displayed on web page).
Once received OTP from bank, customer will enter OTP (YYYY) to web page of bank
host to confirm transaction.
Bank host will certify OTP. If valid, then Bank host will authorize transaction.
Bank host send transaction result (Accept or reject) to NAPAS. NAPAS system will
redirect result back to merchant website.
If transaction authorized, Bank host will debit customer card account and credit
merchant account after calculate fee.
When received redirect result on successful transaction from NAPAS, merchant will
display result on web page and start service deliver process to customer.
At merchant web site, after select product or service and click check out button to start
payment process, merchant website will get customer transaction information and
redirect to NAPAS gateway URL address with data as below:
https://sandbox.napas.com.vn/gateway/vpcpay.do ? + parameter string
Parameter string format: [parameter name]=[parameter value]&[parameter
name]=[parameter value]&[parameter name]=[parameter value]&…
The order of parameter can be exchanged, because we trace by parameter name.
Parameters definition:
Requited Example
Parameter Field type Length
Optional Value
Required Alphanumeric 32
Note: Parameter name can be changed following merchant advice during integration.
Once NAPAS receive URL redirect process from merchant website, gateway will parsing parameter
and calculate checksum (refer to check sum value calculation) value based on those. If both check
sum values are match, then gateway web server will continue to get data from URL then form a
payment order, encrypt and send to bank system.
To get those data and redirect to NAPAS web server gateway, merchant web site should have ability
to create and get value from product selection process of customer then convert to according value
of each parameter. Those will be store into merchant transaction database for cross-check later,
customer support, and customer order processing later.
To response transaction result back to merchant web site, NAPAS web server will redirect
transaction data back to predefine URL (attached in request redirect from merchant to NAPAS or
from merchant profile in NAPAS gateway database).
At NAPAS web site, after sending payment request to Bank web server, this system will ask
customer to enter OTP value before going to authorize transaction. Authorize transaction process is
limit, velocity, card, account status checking before transferring amount of money from customer
card account to merchant account with fee included. Once authorize process complete, NAPAS
gateway will receive response and redirect back to merchant URL with attached parameter string:
Parameters definition:
Requited Example
Parameter Field type Length
Optional Value
Additional Data
vpc_AdditionalData
Optional Alphanumeric 1,255
Required Alphanumeric 32
Note: Parameter name can be changed following merchant advice during integration.
To check the integrity of data transferring through URL redirect, there are required below
items:
Method to calculate checksum data: can using 3DES or MD5 hashing function, most
merchant using MD5 Hashing.
Input data for 3DES or hashing function include string which concatenate all parameter
and checksum key provided by NAPAS for each merchant profile.
If using 3DES function, input data string will be separated every 8 characters and run
through 3DES by 32 length hexa check sum key.
If using MD5 function to make check sum value, just concatenate input data string
plus 32 length check sum key provided by NAPAS.
The length of check sum value is the first 32 character after running above function.
Check sum key should be secure store by merchant website locally.
Before merchant website redirect data to NAPAS gateway server, it will calculate checksum
data and plus to URL string. NAPAS web server, once, received URL string will parsing all
data field and re calculate checksum value again, the matching process will be perform to
check the integrity of data in URL redirection. If any unmatched result, the payment request
will be rejected.
The checksum calculation and checking will be applied same process when NAPAS web
server redirects back response to merchant website.
All data field list in URL string will be calculated checksum exclusive checksum field.
All redirect URL will begin with https://, this mean that data transfer in SSL channel, so
whole data string under encryption or in secure channel.
Only merchant registered and having right checksum key can pass request to NAPAS
gateway.
Those rules can help to reduce risk incase card lost or stolen.
ii. Integration
NAPAS will spend 01 engineer to support to merchant technical team during integration.
During integration, merchant_id and key will be provided for testing purpose only.
The UAT time for run through take around 1 week. After that merchant need to sign to
UAT minute and confirm that they accept working flow and confirm to move to
production later.
During UAT, merchant will be provided user and password to access to Merchant
Transaction Monitoring web site to check transaction.
v. Production Mode
Before moving merchant to production mode, NAPAS need to receive official letter from
merchant writing to request on production mode activate.
At this point in time, new merchant_id and checksum key will be generate and send to
merchant in two separated packages.
In production mode, merchant will be provided web interface to control their customer
transaction. Fraud report will be sent every hour if any.
During production mode, if any charge back or support request, it will be followed by
appendix in contract.
VII.QueryDR Transaction
QueryDR command allows a merchant to search for the current or the most recent
transaction receipt. It also queries for unknown transactions (a transaction request for
which a response was never received) and failed transactions.
The search is performed on the key - vpc_MerchTxnRef, so the vpc_MerchTxnRef field
must be a unique value.
If more than one Transaction Response exists with the same vpc_MerchTxnRef, the most
recent Transaction Response is returned.
Requited Example
Parameter Field type Length
Optional Value
vpc_Version The version of the API being used. The current
version is 2.2
Required Alphanumeric 1,8 2.2
Requited Example
Parameter Field type Length
Optional Value
The version of the Virtual Payment Client being used.
vpc_Version
Required Alphanumeric 1,8 2.0
Additional Data
vpc_AdditionalData
Optional Alphanumeric 1,255
Optional Numeric 2 08
VIII. Refund
Refund allows you to refund funds for a previous purchase or capture transaction from the
merchant's account back to the cardholder's account.
Refunds can only be performed for a previously completed a purchase or capture transaction
for the particular order. The merchant can run any number of refund transactions on the
original transaction, but cannot refund more than has been obtained via a purchase or
capture transaction.
Request Fields
Requited Example
Parameter Field type Length
Optional Value
vpc_Version The version of the API being used. The current
version is 2.1
Required Alphanumeric 1,8 2.1
Note : vpc_TxnResponseCode and VPC_Message will always appear in the DR. Other fields
may not be returned if the transaction was unsuccessful.
Requited Example
Parameter Field type Length
Optional Value
vpc_Version The version of the API being used. The current
version is 2.1
Required Alphanumeric 1,8 2.1
The merchant can only run one 'Void Purchase' transaction on the original 'Purchase'
transaction as it completely removes the purchase transaction as though it never occurred.
The Admin Void Purchase must be run before the acquiring institution processes the batch
containing the original purchase transaction.
Your Payment Provider must enable this function on your Merchant Profile for you to use
either of these methods
Request Fields
Requited Example
Parameter Field type Length
Optional Value
vpc_Version The version of the API being used. The current
version is 2.1
Required Alphanumeric 1,8 2.1
The fields included in a DR from the Virtual Payment Client when using voids are:
Requited Example
Parameter Field type Length
Optional Value
vpc_Version The version of the API being used. The current
version is 2.1
Required Alphanumeric 1,8 2.1
Requited
Parameter Field type Length Example Value
Optional
Indicates the payment gateway type. Be equal
ATM - identified transactions made on the domestic card
gateway.
vpc_PaymentGateway
INT - identified transactions made on the international card
gateway.
A code issued by the Payment Server for the card type used
by the cardholder in the transaction. For a list of card type
vpc_CardType codes, see Card Type Code (see "Card Type Code") .
QueryDR
Refund
1. Card successful
Card Name: NGUYEN VAN A
Card Number: 9704000000000018
Card Expdate: 03/07
2. Card Lock
Card Name: NGUYEN VAN A
Card Number: 9704000000000026
Card Expdate: 03/07
4. Card limit
Card Name: NGUYEN VAN A
Card Number: 9704000000000042
Card Expdate: 03/07
Visa/MasterCard test:
1. MasterCard
Card Number: 5123456789012346
Card Expdate: 05/17
Cvv: 123
2. Visa
Card Number 4005550000000001
Card Expdate: 05/17
Cvv: 123