Confirmation subprocess

Transaction confirmation flow depends on the invoice status and the volume of detected transaction. Main types are grouped below:

Confirm user transaction - detailed view

Rationale

The transaction confirmation subprocess is a cornerstone of the XGateway service, ensuring secure and efficient handling of user payments. It maintains the integrity of payment channels by performing certain checks, filtering out dust payments, and safeguarding against potentially malicious third-party interactions, thereby enhancing the user experience for merchants.

This process is especially important given the dual nature of crypto and bank onramp payment channels:

• Payments are not possible until a bank or crypto account is created.

• Payment channels, once established, can persist beyond the lifecycle of a single invoice, potentially being reused or exposed, increasing the risk of fraud or denial-of-service (DoS) attacks.

To address these challenges, XGateway categorizes payments into three main types, based on the timing and amount of the payment:

Payment Types

1. Non-Invoice Payments

   • These occur when a user sends a payment without a corresponding merchant invoice, such as repeating a prior payment directly from their bank or wallet without initiating a checkout.

   • Non-invoice payments can also occur during a user’s first transaction, though this scenario is less common.

   • Represented as Option A (orange) and Option E (blue) on the diagram.

2. Dust Payments

   • These payments fall below the configured minimum threshold, occurring either before or after invoice activation.

   • Due to the cost of processing payments XGateway filters out dust payments to prevent monetary losses and mitigate DoS risks.

   • Thresholds are customizable per payment channel.

   • Represented as Option B and Option C (red) on the diagram.

3. Invoice Payments

   • Payments linked to an active merchant invoice that meet the minimum value threshold. While the payment amount doesn’t need to exactly match the invoice, it must exceed the dust threshold to be considered valid.

Transaction Confirmation Process

1. Volume Check

   • The transaction amount is checked against configured dust and deposit thresholds for the payment channel.

   • Transactions below the threshold are rejected outright, with the system awaiting a valid payment.

2. Internal Clearance and AML Checks

   • Valid transactions undergo automatic internal clearance and Anti-Money Laundering (AML) checks.

   • Merchants can configure additional checks if required.

3. Escalation for Manual Processing

   • Transactions flagged as suspicious or timing out during clearance escalate to manual processing.

4. Processing Outcomes

   • Rejected Transactions:

     • Transactions failing internal checks are halted. If the user is mid-checkout, a failure notification is displayed.

     • Users can retry the invoice process or file a support ticket using their transaction ID.

     • Merchants may be notified in these cases if configured.

   • Approved Transactions:

     • Transactions passing internal checks proceed to the invoice reconciliation phase.

5. Invoice Reconciliation

   • If an active invoice exists:

     • The user’s balance is updated.

     • The invoice is closed, and a receipt is issued to the user.

     • Notifications are sent to both the user and the merchant.

     • Important: Merchants must verify the invoice details to correctly adjust the user’s balance, as XGateway guarantees only the transferred amount, not whether it fully covers or exceeds the invoice.

   • If no active invoice exists:

     • The system emits a balance change callback for the merchant.

     • Merchants can choose how to handle these payments: accept, ignore, or contact support for further action.

     • Users will not receive a notification for non-invoice payments but their account balance will be updated.