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

Before you can use the special fields listed below, you must contact Galileo to perform setup. The IOANV parameter must be set, and other back-end adjustments must 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 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
    • Four zeros: 0000 (default)
  • 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
        }
    }
  1. Inside the embossed_cards object, the status should be Y. If it is N, skip to Fund the test account.
  2. 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:
ParameterValue
accountNoPRN or CAD of the card account
cardExpiryDateexpiry_date as YYYY-MM
cardSecurityCodecard_security_code (In CV it is always 123)
cardNumberLastFourOptional. Last four digits of card_number. If there is more than one card associated with the PRN, you must populate this parameter.
  1. 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:

ParameterValue
accountNopmt_ref_no of the card account
amountTesting amount, such as 1000
typeRL

General guidelines when simulating card transactions:

  • 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 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.
  • When Create Simulated Card Authorization returns the auth_response_code, the auth_response_description usually contains Success, even for denied authorizations. In a future enhancement the description will correspond to the code.
  • 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:
  • If you need to troubleshoot with Galileo, provide the complete request and response for each transaction to investigate.