Setup for Card Transaction Simulation

This guide contains setup instructions that should be performed prior to simulating card transactions in the CV environment. See Simulating Card Transactions for instructions for the actual simulations.

🚧

Warning

Do not follow this procedure in Production. The transaction-simulation endpoints are not valid in Production.

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

• About Transactions — A general guide to how transactions are represented in the Galileo system.
• About Card Transactions — A general overview of how card transactions work, including the phases that a card transaction passes through
  • Networks — Credit and debit network types and how transactions are routed
  • Authorization — Authorization requests and their variants such as preauthorization, incremental authorizations, and partial authorizations
  • Settlement — Settlements, backouts, and completions
  • Crediting Cardholder Accounts — 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 Production. Work with Galileo to complete product setup.

Initial setup

If you are a longtime Galileo client, you may need to contact Galileo to enable the IOANV parameter for every product you intend to test so that you can use these parameters. Newer Galileo clients are already set up to use these parameters:

• 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 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 Direct POST or Direct Render 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 Creating an Account. 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 — PRN of the account
• card_id — Card ID or CAD
• Last four digits of card_number
• card_security_code — The 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 Get Card 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.

"response_data": {
    	"card_number": "515567XXXXXX9075",
    	"expiry_date": "2026-09-12",
    	"card_security_code": "123",
    	"status": "Y",
    	"card_id": "5530",
    	"external_card_id": null,
    	"pmt_ref_no": "999102163165",
    	"first_name": "Juan",
    	"middle_name": "",
    	"last_name": "Alvarez",
    	"encrypted_card_number": null,
    	"encrypted_expiry_date": null,
    	"embossed_cards": [
        	{
            	"status": "Y",
            	"created_date": "2022-09-12",
            	"emboss_date": "",
            	"expiry_date": "2026-09-12",
            	"shipping_type": "standard",
            	"product_id": "3333"
        	}
    	],
    	"freeze_info": {
        	"status": "Unfrozen",
        	"start_date": null,
        	"end_date": null
    	},
    	"pin_fail_count": "0",
    	"pin_fail_date": null,
    	"spend_controls": {
        	"available_credit": null,
        	"single_use": null,
        	"credit_limit": null
    	}
	}

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 Activate Card with these parameters (See Card activation in Setting Up a Card Program for information about other activation options):

2. To verify that the card has been activated, call Get Card 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 Create Payment 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 for Create Simulated Card Authorization. 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 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 Simulated Transaction Types enumeration.
• After using Create Simulated Card Authorization, always capture the auth_id in the response.
• When using Create Simulated Card Settlement:
  • Either the merchantName or authId parameter must be populated.
  • 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:
    • Get Authorization History — Retrieve only authorizations that have not been settled, completed, reversed or expired.
    • Get Account Overview — Unsettled authorizations are in the authorizations object.
    • Get All Transaction History — Retrieve all entries in the ledger.
  • To view settled transactions:
    • Get Transaction History — Retrieve only transactions that have settled. Does not show backouts.
    • Get Account Overview — Posted transactions are in the transactions object.
    • Get All Transaction History — Retrieve all entries in the ledger, including backouts and expiries.

👍

Tip

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