This guide contains setup instructions that should be performed prior to simulating card transactions in the <<glossary:CV>> environment. See <a href="doc:simulating-card-transactions" target="_blank">Simulating Card Transactions</a> for instructions for the actual simulations.

🚧

Warning

Do not follow this procedure in <<glossary:Production>>. The transaction-simulation endpoints are not valid in Production.

Before simulating card transactions, you should be familiar with the concepts in these guides:

<!--

• Testing in CV

-->

• <a href="doc:about-transactions" target="_blank">**About Transactions**</a> — A general guide to how transactions are represented in the Galileo system.

• <a href="doc:about-card-transactions" target="_blank">**About Card Transactions**</a> — A general overview of how card transactions work, including the phases that a card transaction passes through

  • <a href="doc:networks" target="_blank">**Networks**</a> — Credit and debit network types and how transactions are routed

  • <a href="doc:authorization" target="_blank">**Authorization**</a> — Authorization requests and their variants such as preauthorization, incremental authorizations, and partial authorizations

  • <a href="doc:settlement" target="_blank">**Settlement**</a> — Settlements, backouts, and completions

  • <a href="doc:crediting-cardholder-accounts" target="_blank">**Crediting Cardholder Accounts**</a> — Card transactions that move funds into cardholder accounts such as reversals, merchant credits and card loads

📘

Note

This guide assumes that you have already set up your products in CV with the same characteristics that you will be using in <<glossary:Production>>. Work with Galileo to complete product setup.

## Initial setup

Before you can use the special fields listed below, you must contact Galileo to perform setup. The IOANV parameter must be set for every product you intend to test, and other back-end adjustments must also be made:

• `settleAmount`

• `settleCurrencyCode`

• `cardBillingAmount`

• `cardBillingCurrencyCode`

• `mcc`

• `originalAuthId`

• `specialFunctions`

• `posEntryMode`

• `requesterId`

• `walletId`

• `latitudeAndLongitude`

• `partialAmount`

• `partialForeignAmount`

• `cashbackAmount`

• `cashAdvanceAmount`

• `pin`

• `transType`

### PIN setup

Perform this step only if you want to simulate PIN or ATM transactions. Use one of these ways to set the PIN in the CV environment:

• In your CV instance of the <<glossary:CST>>, after account creation.

• Set CASPO to automatically set the PIN to one of these values. If you set CASPO just for the CV environment, make sure you remove CASPO before pushing your configuration to Production:

  • Last 4 digits of home phone

  • Last 4 digits of mobile phone

  • Last 4 digits of PRN

  • No PIN

• Use the <a href="doc:direct-post-pin-set-procedure" target="_blank">Direct POST</a> or <a href="doc:direct-render-pin-set-procedure" target="_blank">Direct Render</a> PIN-set procedure. You will have to contact Galileo to set these methods up in CV. Keep in mind that there will be differences between the CV setup and Production, such as different submitter IDs.

## Create the test account

Follow the instructions in <a href="doc:creating-an-account" target="_blank">Creating an Account</a>. The `prodId` must be for a product with a card so that card transactions will be valid.

From the Create Account endpoint response you should capture these values for future use:

• `pmt_ref_no` — <<glossary:PRN>> of the account

• `card_id` — Card ID or CAD

• Last four digits of `card_number`

• `card_security_code` — The <<glossary:CVV>>

### Verify card creation

After creating the card account, wait 15–20 minutes before performing this step to allow the emboss process to run.

1. Call <a href="ref:post_getcard" target="_blank">Get Card</a> with the `pmt_ref_no` or `card_id` of the card as the `accountNo`.

2. Verify that the `embossed_cards` object is populated. If it is not, wait 5 more minutes and try again.

3. Inside the `embossed_cards` object, the `status` should be `Y`. If it is `N`, skip to [Fund the test account](🔗).

4. Capture the value of `expiry_date`.

### Activate the card

Skip this step if the card status is `N`, such as with a Digital First card or a virtual card.

1. Call <a href="ref:post_activatecard" target="_blank">Activate Card</a> with these parameters:

2. To verify that the card has been activated, call <a href="ref:post_getcard" target="_blank">Get Card</a> again. Inside the `embossed_cards` object you should see `status: N`.

### Fund the test account

If you are testing a debit account, you will need to add funds to the account. If you are testing a credit card, make sure the credit limit is set to an adequate testing amount. For secured credit cards, contact Galileo for the steps to fund the card. The funds that are created for the debit account are simulated funds. You do not need to set up a source account to provide them. The `RL` type means "Retail Load."

For a debit account, call <a href="ref:post_createpayment" target="_blank">Create Payment</a> with these parameters:

## General guidelines when simulating card transactions

📘

Note

Not all of the `transType` and `specialFunctions` values are currently working as expected. The individual simulations in the guides on this site are known to work.

• The simulator simulates transactions over Visa credit or Mastercard credit rails. Transactions over debit and ATM networks such as Maestro, Interlink, Plus, and Allpoint cannot be simulated.

• The `merchantName` parameter is required. It's a good idea to give each test transaction a unique merchant name so that you can more easily distinguish the transactions from each other when retrieving transaction data.

• The simulator will fill in a random value for these parameters when you leave them blank:

  • `acquirerId`

  • `terminalId`

  • `merchantId`

  • `mcc`

• Use a genuine `mcc` (ISO 18245) to test upcharges and <<glossary:MCC>> blocks. In this guide, the MCCs correspond to the merchant type specified in `merchantName`.

• The `transType` for Visa is often different from the `transType` for Mastercard for the same function. Make sure you check the correct table in the <a href="ref:api-reference-simulated-transaction-types" target="_blank">Simulated Transaction Types</a> enumeration.

• After using Create Simulated Card Authorization, always capture the `auth_id` in the response.

• When using Create Simulated Card Settlement, you can leave the `amount` field blank. The simulator ignores any value in `amount` and so will automatically settle for the amount of the authorization.

• After creating the simulated transactions, use these endpoints to see the results:

  • To view an authorization or preauthorization before it is settled:

    • <a href="ref:post_getauthhistory" target="_blank">Get Authorization History</a> — Retrieve only authorizations that have not been settled, completed, reversed or expired.

    • <a href="ref:post_getaccountoverview" target="_blank">Get Account Overview</a> — Unsettled authorizations are in the `authorizations` object.

    • <a href="ref:post_getalltranshistory" target="_blank">Get All Transaction History</a> — Retrieve all entries in the ledger.

  • To view settled transactions:

    • <a href="ref:post_gettranshistory" target="_blank">Get Transaction History</a> — Retrieve only transactions that have settled. Does not show backouts.

    • <a href="ref:post_getaccountoverview" target="_blank">Get Account Overview</a> — Posted transactions are in the `transactions` object.

    • <a href="ref:post_getalltranshistory" target="_blank">Get All Transaction History</a> — Retrieve all entries in the ledger, including backouts and expiries.

• If you need to troubleshoot with Galileo, provide the complete request and response for each transaction to investigate.