Skip to main content
Payment webhooks always use the transaction envelope. The top-level event stays transaction; the concrete event name is in data.event_type.

​
Example delivery payload

{
  "id": "evt_pay_1001",
  "event": "transaction",
  "api_version": "v1",
  "data": {
    "id": "tr_3001",
    "event_type": "transaction.pending",
    "correlation_id": "order_3001",
    "method": "voucher",
    "status": "pending",
    "amount": 125000,
    "currency": "MXN",
    "voucher": {
      "barcode": "646180123456789012",
      "digitable_line": "646180123456789012",
      "url": "https://provider.example/pay/order_3001",
      "expiration_date": "2026-05-12T23:59:59.000Z",
      "instructions": "Pay using the bank transfer reference before the expiration date.",
      "receipt_url": null
    }
  }
}

​
ACK response

{
  "received": true
}

​
Event names emitted today

  • transaction.created
  • transaction.pending
  • transaction.paid
  • transaction.cancelled
  • transaction.refunded
  • transaction.partially_refunded
  • transaction.chargedback
  • transaction.three_ds_required

​
Common ingestion error

{
  "error": "missing_event_id"
}
Fix: deduplicate by the top-level event id, not by transaction ID, because the same transaction can emit more than one business event over time.

​
Mapping guidance

  • Use transaction.paid to release goods or services.
  • Keep the order open on transaction.pending.
  • For method: "voucher", transaction.pending can also carry payment instructions in data.voucher. Show the returned url, digitable_line, barcode, or instructions and keep waiting for transaction.paid.
  • Use refund and chargeback events to drive finance and support flows.
  • Route transaction.three_ds_required back into your card challenge flow.