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:| Event Type | Description | When Triggered |
|---|---|---|
transaction.created | Transaction created | When a new transaction is recorded in the system |
transaction.updated | Transaction updated | When a transaction’s status or fields are updated (full snapshot in payload) |
transaction.status_changed | Status transition | When a transaction’s status changes (dashboard, API, or other flows). Narrow payload focused on previousStatus → status. |
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
The event type (e.g.,
transaction.created)ISO 8601 timestamp when the event occurred
Your organization ID
The transaction’s UUID in Gu1
Your external ID for the transaction
Transaction type:
payment, transfer, withdrawal, etc.Current transaction status:
CREATED, PROCESSING, SUSPENDED, SENT, SUCCESSFUL, DECLINED, REFUNDED, EXPIREDTransaction amount in original currency
ISO 4217 currency code (e.g.,
USD, EUR, MXN)Event-Specific Payloads
transaction.created
Sent when a new transaction is recorded in the system.transaction.updated
Sent when an existing transaction is updated (e.g., status change).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 ontransaction. After the change, the rules engine may re-run; when applicable, rulesExecutionSummary mirrors the summary returned by the transaction API for that evaluation.
New transaction status after the change (e.g.
SUCCESSFUL, DECLINED, REFUNDED).Status before the change.
Snapshot identifiers:
id (Gu1 UUID), externalId, type, and current status.Optional. Present when rule evaluation metadata is available for this transition (same conceptual shape as in API responses).
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
Use externalId for Lookup
Use externalId for Lookup
The webhook includes
externalId which is the ID you provided when creating the transaction. Use it to look up the transaction in your database.Store Gu1 Transaction IDs
Store Gu1 Transaction IDs
Save Gu1’s
transactionId in your database. This allows you to query transaction details later if needed.Handle Idempotency
Handle Idempotency
You may receive the same webhook multiple times. Use the
transactionId and event to ensure you process each event only once.Return 200 Quickly
Return 200 Quickly
Always return a 200 status code as quickly as possible to confirm receipt. Process the webhook asynchronously if needed.
Verify Signatures
Verify Signatures
Always verify the
X-Webhook-Signature header to ensure the webhook is authentic. See the security guide for details.Troubleshooting
Not Receiving Webhooks
Not Receiving Webhooks
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
Signature Verification Failing
Signature Verification Failing
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)
Receiving Duplicate Webhooks
Receiving Duplicate Webhooks
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