Skip to main content

Overview

Transaction webhook events allow you to receive real-time notifications when transactions are created or updated in your organization. Gu1 automatically sends HTTP POST requests to your configured webhook endpoint, enabling you to automate transaction monitoring workflows, fraud detection, and regulatory compliance.

Why Use Transaction Webhooks?

Real-Time Monitoring

Receive instant notifications about new or updated transactions

Fraud Detection

Implement additional security checks in real-time

Workflow Automation

Trigger automated processes based on transaction activity

Audit and Compliance

Keep audit logs synchronized across all your systems

Available Events

Gu1 sends webhooks for the following transaction events:
The transaction.created and transaction.updated events are currently in development and will be activated soon. This documentation is available to prepare your integration.Available today: transaction.status_changed is emitted when the status changes. Gu1 may also send transaction.updated for the same change (richer payload with amounts, origin/destination, etc.). Subscribe to one or both depending on whether you need the full transaction snapshot or only the transition.

Event Payload Structure

All transaction webhook events follow this standard structure:

Common Payload Fields

string
The event type (e.g., transaction.created)
string
ISO 8601 timestamp when the event occurred
string
Your organization ID
string
The transaction’s UUID in Gu1
string
Your external ID for the transaction
string
Transaction type: payment, transfer, withdrawal, etc.
string
Current transaction status: CREATED, PROCESSING, SUSPENDED, SENT, SUCCESSFUL, DECLINED, REFUNDED, EXPIRED
number
Transaction amount in original currency
string
ISO 4217 currency code (e.g., USD, EUR, MXN)

Event-Specific Payloads

transaction.created

Sent when a new transaction is recorded in the system.
Use case: Trigger additional fraud checks, update account balances in real-time, or initiate compliance processes.

transaction.updated

Sent when an existing transaction is updated (e.g., status change).
Use case: Notify customers about their transaction status, update dashboards in real-time, or trigger post-transaction workflows.

transaction.status_changed

Sent when a transaction’s status changes (for example after a manual status update in Transaction Monitoring or via the API). The payload is intentionally compact: it carries the new and previous status plus identifying fields on transaction. After the change, the rules engine may re-run; when applicable, rulesExecutionSummary mirrors the summary returned by the transaction API for that evaluation.
string
New transaction status after the change (e.g. SUCCESSFUL, DECLINED, REFUNDED).
string
Status before the change.
object
Snapshot identifiers: id (Gu1 UUID), externalId, type, and current status.
object
Optional. Present when rule evaluation metadata is available for this transition (same conceptual shape as in API responses).
Use case: Drive workflows that only care about status transitions, audit trails, or webhooks that must stay small. Prefer transaction.updated if you need amounts, origin/destination, and other fields in the same notification.

Code Examples

Node.js - Handling Transaction Events

Python - Handling Transaction Events

Best Practices

The webhook includes externalId which is the ID you provided when creating the transaction. Use it to look up the transaction in your database.
Save Gu1’s transactionId in your database. This allows you to query transaction details later if needed.
You may receive the same webhook multiple times. Use the transactionId and event to ensure you process each event only once.
Always return a 200 status code as quickly as possible to confirm receipt. Process the webhook asynchronously if needed.
Always verify the X-Webhook-Signature header to ensure the webhook is authentic. See the security guide for details.

Troubleshooting

Check these items:
  • Webhook URL is publicly accessible via HTTPS
  • Webhook is configured and enabled in dashboard
  • Subscribed to correct event types
  • Endpoint returns 200 status code within 30 seconds
  • Check server logs for received requests
  • Transaction events are currently in development - confirm they are enabled for your organization
Common causes:
  • Using wrong secret (check dashboard for current secret)
  • Verifying signature on parsed JSON instead of raw body
  • Secret not saved correctly after webhook creation
  • Encoding issues (ensure UTF-8)
See the security guide for proper implementation.
This is normal behavior. Webhooks may be sent multiple times due to network issues, timeouts, or retries.Always implement idempotency using the webhook’s transactionId and event type.

Next Steps

Entity Events

Handle entity lifecycle events

KYC Events

Process KYC verification updates

Webhook Security

Secure your webhook endpoints

Configuration

Configure webhook settings