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:

1. Go to Fusion Management Console login page
2. Enter your 10 digit phone number or email ID.
3. Verify using an OTP sent to the registered phone number or email ID.
4. Enter your password that was set at the time of first time login.

Landing Page

Once you login, you will see an icon for payment simulator on FMC landing page.

You can click on the Payment Simulator icon and you will be redirected to Simulator home page without further login.

Over here Your card Network is already embedded into the Simulator, Simulator supports all card networks Fusion is integrated with viz.

1. Mastercard
2. Visa
3. Rupay
4. Amex

If you are testing the integration on UAT environment, network will be set to “UAT Network” by default for carrying out your simulations.

Simulation Conditions

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 and merchant details are constant at a card network level.

In case you need to try out transactions on a specific merchant, you can select the merchant from the list of merchants available to you

Definitions for all the fields are provided in the Field Description section.

Card type

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:

1. Magstripe cards, and
2. EMV cards

Transaction type

For each card type, you can simulate different scenarios e.g. for EMV cards you can simulate:

1. POS transaction
2. ATM transaction
3. eCommerce transaction
4. POS reversal transaction
5. eCommerce 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 card details and need to enter simulation amount to simulate a transaction.

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:

1. Physical cards or
2. 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:

1. Card Number / PAN
2. Card Expiry
3. Card CVV1 / CVV2 / iCVV

You can either directly enter your card details on your own or you can search for the cards available for you for a simulation.

In order to search for the card details, you can click on “search for card” functionality and enter the mobile number or email id which is associated with your card.

once the card details appear, you can click on the card number and the details will be auto filled in the card details section of the main simulator screen.

Depending on the type of transaction, you need to enter CVV1 / CVV2 / iCVV.

1. Magstripe - ATM - CVV1
2. Magstripe - POS - CVV1
3. Magstripe - E-COM - CVV2
4. EMV - ATM - ICVV
5. EMV - POS - ICVV
6. EMV - E-COM - CVV2

For ecommerce transactions OTP is required for second factor authentication, while for POS/ ATM transactions, card PIN is required.

Transaction Amount

Amount entered for the transaction has to be in paisa, so for simulating INR 1 transaction, the amount has to be 100.

Reversal Simulations

For simulating reversal payment, you need to provide the following details:

1. Transaction type that you want to reverse (ATM/ POS/ ecommerce)
2. Amount that you want to reverse (this can be full or partial transaction amount)
3. Details of original transaction that is to be reversed
   1. RRN
   2. STAN
   3. dateTimeTransmission
   4. timeLocalTransmission
   5. 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.

In the output section, you can see all the values which you will receive in output of the simulation and which would be further required to be used in the reversal scenario as well

1. RRN
2. STAN
3. dateTimeTransmission
4. timeLocalTransmission
5. dateLocalTransmission

You can also find the simualtion response and the payment event associated with the current payment state as well in the output.

In the Input section, you can find the details of merchant, amount of the transaction ,card type and transaction type which is simulated.

Simulation History

Simulation history consists the details of latest 20 simulations which have been performed by the logged in user using the payment simulator until then. You can see the details of the transaction in the simulation history as well.

You can click on the 3 dots in the end and see the input, output and payment event details related of the simulation

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.