What is Card Payment Simulator?
Card payment simulator is a tool for the developers working with Fusion APIs to try out card transactions in a testing environment. Payment Simulator simulates the real behavior of Magstripe or EMV cards without the need for any physical cards. It enables the merchant terminal testing by eliminating the dependency on physical test cards. If available, physical cards can also be used on Simulator. Simulator can be used for all major card schemes and different simulation conditions e.g. ATM, POS, ecommerce, reversals etc.
Getting Started
Fusion card payment simulator requires user authentication to access the tool. Fusion team will provide the access to your dev team to start using the simulator.
Logging In
For logging in, you’ll have to go through the following steps:
- Go to https://prod-card-simulator.gw.zetapay.in/.
- Enter your 10 digit phone number or email ID.
- Verify using an OTP sent to the registered phone number.
- Enter your password that was set at the time of first time login.
Landing Page
Once you login, you will see the payment simulator landing page.
Over here you can select the card network for which you want to simulate transactions. Simulator supports all card networks Fusion is integrated with viz.
- Mastercard,
- Visa,
- Rupay, and
- Amex
If you are testing the integration on UAT environment, please use “UAT Network” for carrying out your simulations.
Simulation Conditions
For each network, there can be multiple scenarios that you may want to simulate transactions for. These scenarios / simulation conditions arise out of available card types and transaction types that you may want to test out.
For example, for ‘UAT Network’, you can simulate transactions for:
- Magstripe cards, and
- EMV cards
For each card type, you can simulate different scenarios e.g. for MagStripe cards you can simulate:
- POS transaction
- ATM transaction
- eCommerce transaction
- Reversal transaction
Depending on your requirements, you need to select appropriate simulation conditions.
Simulating transactions
After you have selected the simulation condition/ scenario, you would primarily require merchant details and card details to simulate a transaction.
Merchant details
Merchant details are pre-filled on the simulator UI. You need not change merchant details to simulate any transactions. The merchant details entered on the simulator is a test merchant created by Fusion for simulation purposes.
In case you need to try out transactions on a specific merchant, you can update the required details for the merchant. These details include:
- MID
- TID
- MCC
- Merchant Name
- Merchant City
- Merchant State
- Merchant Country
Definitions for all the fields are provided in the Field Description
section.
Card details
You can generate card details from Fusion Cards SDK shared with you. This will allow you to card details for the cards that you have issued to account holders created for testing purposes. With Fusion APIs, you can create either:
- Physical cards or
- Virtual cards
While virtual cards can be used for simulating only ecommerce transactions, you can create physical cards to test ATM and POS transactions along with ecommerce transactions.
For simulating any transactions, the following card details are required:
- Card Number / PAN
- Card Expiry
- Card CVV1 / CVV2 / iCVV
Depending on the type of transaction, you need to enter CVV1 / CVV2 / iCVV.
- Magstripe - ATM - CVV1
- Magstripe - POS - CVV1
- Magstripe - E-COM - CVV2
- EMV - ATM - ICVV
- EMV - POS - ICVV
- EMV - E-COM - CVV2
For ecommerce transactions OTP is required for second factor authentication, while for POS/ ATM transactions, card PIN is required.
Amount entered for the transaction has to be in paisa, so for simulating INR 1 transaction, the amount has to be 100.
For simulating reversal payment, you need to provide the following details:
- Transaction type that you want to reverse (ATM/ POS/ ecommerce)
- Amount that you want to reverse (this can be full or partial transaction amount)
- Details of original transaction that is to be reversed
- RRN
- STAN
- dateTimeTransmission
- timeLocalTransmission
- dateLocalTransmission
These details are available in the acquirer response after the transaction simulation is completed. Definitions for all the fields are provided in the ‘Field Description’ section.
Acquirer Response
After the transaction simulation is initiated, we get the acquirer response with all details for the processed transaction.
Response helps us understand if the transaction was successful or not. Action code
field in the response with value 00
indicates transaction success, any other value for action code represents transaction failure.
Field Description
BIN Type
- BIN stands to ‘Bank Identification Number’. Select the appropriate option (Rupay, Mastercard, Mastercard cipher etc.) depending on the type of card you want to test.
Card Type
-
Magstripe: The ”stripe” on the back of every physical card is a magnetic stripe, often called a magstripe. This stripe is encoded with sensitive card data such as the PAN (primary account number), expiry, and account holder name among other things. A magstripe transaction is done with a quick swipe of the card through a card reader.
-
EMV: EMV stands for ‘Europay, MasterCard, Visa’. Cards with embedded EMV chips are called EMV cards. For EMV cards, the chip contains sensitive card data like PAN, expiry etc. An EMV transaction is done by dipping the card in a card reader / ATM for it to read the card chip data.
Transaction Type
-
POS: POS stands for ‘Point of Sale’. All transactions initiated using a physical card reader (POS machine) - either by swiping the magstripe or by dipping the EMV chip - are called POS transactions. These transactions are also called card present (CP) transactions as the card is physically present at the merchant location at the time of transaction.
-
ECOMMERCE: Transactions performed at any online website (using payment gateways) are referred to as eCommerce transactions. These transactions are also called CNP or card not present transactions as only card details (PAN, CVV2, expiry) and 2nd factor authentication is required to complete the transaction. The card by itself is not required to be physically presented for the transaction.
-
ATM: All ATM cash withdrawals are referred to as ATM transactions.
-
Payment Reversal: These are the transactions initiated by the merchant to credit the cardholder for any transaction already completed by the cardholder. Reversal payments can be for both POS and ecommerce transactions.
Card Details
-
PAN: PAN stands for ‘Primary Account Number’. It is the unique 16 digit card number assigned to every physical or virtual card.
-
Expiry: Every card has an expiry date in terms of expiry month & expiry year. Card is no longer valid after expiry period. Expiry date is available for both physical and virtual cards.
-
CVV: CVV stands for ‘Card Verification Value’. It is a security code required to complete the transaction.
- CVV / CVV1: It is stored in the card’s magnetic stripe and is used for ATM and POS transactions where magstripe is used to read the card data.
- iCVV: iCVV is integrated in the card’s EMV chip data and is used for ATM and POS transactions where EMV chip is used to read the card data.
- CVV2: CVV2 is printed at the back side of the card (besides signatures strip). It is used for eCommerce or card not present (CNP) transactions.
-
PIN: PIN stands for ‘Personal Identification Number’. It is a 4 digit numeric code required to complete POS transactions.
-
OTP: OTP refers to ‘One Time Password’. It is a 4 digit or 6 digit numeric code send to the cardholder’s registered mobile number. It is required for completing the 2nd factor authentication for ecommerce transactions.
Merchant details
-
Merchant Name: The business name of the merchant as registered with the acquiring bank.
-
MID: MID stands for ‘Merchant Identification Number’. The MID uniquely identifies a merchant that is processing payments through a network. Since there are millions of retailers on the internet, this number guarantees that a dealer is recognized correctly and transactions are routed through the appropriate channels.
-
TID: TID stands for ‘Terminal ID’. A merchant registered for payment processing with a MID may have multiple stores, outlets, terminals, checkouts etc. TID identifies the exact terminal from where a payment is initiated. Every merchant can have one or more terminals.
-
MCC: MCC stands for ‘Merchant Category Code’. MCCs are used to identify the type of business in which a merchant is engaged. Payment networks use MCCs to classify merchants and businesses by the type of goods or services provided. Networks, issuers and acquirers can use MCCs to categorize, track and restrict transactions.
-
Merchant City: City as per registered address of the merchant.
-
Merchant State: State as per registered address of the merchant.
-
Merchant Country: Country as per registered address of the merchant.
Transaction Details
-
RRN: RRN stands for ‘Retrieval Reference Number’. It is the key to uniquely identify a card transaction based on the ISO 8583 standard.
-
STAN: STAN stands for ‘System Trace Audit Number’. STAN is generated by the issuer and can be used to identify a transaction. STAN is a trace ID number used internally by the isser
-
Date Local Transaction: Date of the transaction on MMYY format. This is returned in the acquirer response for the simulated transaction.
-
Time Local Transaction: Time of the transaction. This is returned in the acquirer response for the simulated transaction.
-
Date Time Transmission: Combination of date & time of the transaction. This is returned in the acquirer response for the simulated transaction.