Simulate Transactions

Note: This guide can be used for any card product, except fleet card products. To simulate transactions for fleet card products, see Simulate Fleet Transactions.

1. Review Transaction Lifecycle guide
2. A Highnote account
3. An API Key or the API Explorer
4. A card product, financial account, and payment card

Warning: The Highnote test environment lets you freely explore the platform features and functionality. It is intended for experimenting, building integrations, and training your team.

To ensure the security of your real-world data, do not enter production data in the test environment. Production data includes sensitive information like customer details, financial data, or personally identifiable information (PII).

Use only dummy or test data explicitly created for testing purposes in the test environment.

You can use the Highnote API to simulate transactions in the test environment. Simulating transactions helps test the following use cases and card product settings:

• Transactions at different merchant types
• Different transaction amounts
• International transactions
• Spend rules and velocity controls
• Collaborative authorization flow

This guide provides steps for simulating transactions using the Highnote API. For steps on simulating transactions in the dashboard, see Simulate authorizations.

Simulated authorizations use the same logic as real authorizations from card networks such as Mastercard and Visa. In the test environment, authorizations are approved or declined based on your card product logic and authorization controls.

Use the following mutation to simulate an authorization in your test environment:

Once a transaction clears, funds are transferred to the merchant from the account holder's financial account. Clearing occurs in one of the following ways:

• With an authorization, immediately after
• In batches after authorizations are approved

Use the following mutation to simulate clearing. For partial clearings, set the value input variable to an amount less than the original transaction, for example:

Copy code snippet

Some transactions send authorization and clearing events in a single message. Use the following mutation to simulate an authorization and clearing event:

An authorization can be reversed if it has not cleared. Reversing an authorization releases funds from "pending" status and returns the funds to the account holder.

Specifically:

• You can do a full reversal before clearing
• You can do a partial reversal after a partial clearing (of the non-cleared authorized amount)
• You cannot reverse at all after a full clearing -- this requires a refund

Use the following mutation to simulate a reversal. Full reversals are the default. For partial reversals, set the value input variable to an amount less than the original authorization, for example:

Copy code snippet

Note: You cannot simulate refunds linked to a previous transaction. Simulating a refund results in a new transaction with its own id and transactionEvent.

Refunds can be simulated for cleared transactions. When simulating a refund, you can refund the total or partial amount of the original transaction.

When you use the simulateRefund mutation, you will receive a ClearingEvent in response. Use the following mutation to simulate a refund:

To automate your integration, subscribe to the following notification events:

• Payment card authorization
• Payment authorization and clear
• Payment card cleared

The details provided in the payloads from these events can be used for the following use cases:

• Automate your application or website's transaction processing workflows
• Create account holder notifications and alerts