Flagged Transactions

VoPay automatically reviews every transaction at the moment it is created. If a transaction matches certain risk criteria — for example, it looks like an accidental duplicate — it is flagged and paused before it is submitted for processing. A flagged transaction is not rejected: it simply waits until the flag is resolved, either by you (via the API) or automatically by VoPay.

This page explains why transactions get flagged, how to detect flagged transactions, and how to resolve them.

How it works

1. You submit a transaction (EFT, ACH, Interac, RTP/RTR, wire, etc.).
2. VoPay runs a series of automated checks before the transaction is queued for submission.
3. If a check matches, the transaction is flagged and held — it will not be submitted to the payment network while an unresolved flag is present.
4. The flag is resolved in one of three ways:
   • You confirm the transaction using the POST /account/transaction/confirm endpoint, and it proceeds normally.
   • You cancel the transaction if it was not intentional.
   • The flag resolves automatically — some holds (such as insufficient funds or delayed processing) clear on their own, and unresolved flags are cancelled after a timeout (see Automatic resolution).

Detecting flagged transactions

In the transaction creation response

When a transaction is flagged at creation, the API response includes a Flagged field describing the reason:

{
  "Success": true,
  "ErrorMessage": "",
  "TransactionID": "45563",
  "Flagged": "The transaction has been flagged for the following reason(s) and may experience a delay in processing: This transaction has been flagged as a potential duplicate due to similarities with transactions 45561. You can remove the flag by using the /account/transaction/confirm endpoint."
}

In the transaction listing

Use the IsFlagged query parameter on GET /account/transactions to retrieve transactions that currently have an unresolved flag:

GET /api/v2/account/transactions?IsFlagged=true

Each transaction in the response includes a TransactionFlag field. For flagged transactions it contains the flag type and, for duplicates, the IDs of the related transactions:

{
  "TransactionID": "45563",
  "TransactionStatus": "pending",
  "TransactionFlag": "duplicate - 45563,45561"
}

An empty TransactionFlag means the transaction is not flagged (or its flag has already been resolved).

Flag types you can action

These flags are surfaced to you through the API and can be cleared with the confirm endpoint.

Potential duplicate (duplicate)

Raised when a new transaction closely matches another recent transaction on your account. Two transactions are considered potential duplicates when all of the following match, within a 3-hour window:

• Same transaction type (e.g., both EFT withdrawals)
• Same amount and currency
• Same recipient (same bank account and name, or for Interac transactions, the same email address or phone number)
• The earlier transaction is still active (not already successful, failed, or cancelled)

Both the new and the original transaction are flagged, and the flag message lists the related transaction IDs so you can compare them.

How to avoid duplicate flags for intentional repeat payments:

• Include an IdempotencyKey when creating the transaction. Transactions submitted with an idempotency key are treated as intentional and are never flagged as duplicates.
• If your use case regularly involves identical back-to-back payments, duplicate detection can be adjusted for your account — contact your account manager.

High-risk IP address (high-risk-ip)

Raised when a transaction originates from an IP address that threat-intelligence data classifies as high risk. IP addresses on your account's authorized IP list are exempt.

If the transaction is legitimate, confirm it to release it. This check is an optional account feature; talk to your account manager about enabling or tuning it.

Potential fraud — Interac (interac-fraud)

Interac bulk payout transactions may be flagged as potentially fraudulent by the payment network. Confirming the transaction both releases the hold and reports the transaction as legitimate, which helps prevent similar false positives.

Automatic holds

These holds are applied and released by VoPay automatically. They appear in the transaction's status history, and no action is required from you unless noted.

Resolving a flag

Confirm the transaction

If the flagged transaction is legitimate, confirm it:

POST /api/v2/account/transaction/confirm

{
  "Success": true,
  "ErrorMessage": "",
  "TransactionID": "45563",
  "TransactionConfirmed": true
}

Confirming clears all actionable flags on the transaction and releases it for processing in the next submission cycle.

Cancel the transaction

If the flag caught a genuine mistake (for example, an accidental double submission), cancel the unwanted transaction with the standard POST /transaction/cancel endpoint instead of confirming it.

Automatic resolution and timeouts

Best practices

• Use idempotency keys. Passing a unique IdempotencyKey with every transaction prevents duplicate flags on intentional repeat payments and protects you against accidental double submissions.
• Monitor for flags. Poll GET /account/transactions?IsFlagged=true (or check the Flagged field on creation responses) so flagged transactions don't sit unnoticed.
• Act promptly. Unresolved flags cancel the transaction after 7 days — confirm or cancel well before then to avoid unexpected cancellations.
• Review before confirming. The flag message includes the related transaction IDs for duplicates; verify the earlier transaction before releasing the new one.