Skip to main content

Processing the payload

Once you have verified both signatures, you can read the message. The payload is carried base64-encoded inside the CloudEvent, so there are three steps: parse the envelope, decode the payload, then deserialize it into your own model.

The three steps​

  1. Parse the CloudEvent envelope (the outer JSON you received).
  2. Base64-decode data_base64 to recover the message JSON.
  3. Deserialize the message JSON into your domain model.

Use the type field to decide which model to deserialize into — for example global.rtgs.TransactionStatusNotificationV1 is a payment lifecycle update, global.rtgs.PayawayFundsV1 is an inbound payment notification to the receiving participant. The decoded payload is ISO 20022 / FIX-compatible JSON; see Event types reference for the full list of type strings and their payload structures.

Processing a Webhook Payload →

Deduplicate before acting​

Because delivery is at least once, the same notification can arrive more than once. Deduplicate before processing, using either:

  • the CloudEvent id (identical across retries of the same delivery), or
  • the ISO 20022 GroupHeader message identifier inside the decoded payload.

Try it locally​

You can simulate a delivery to your endpoint with curl. Save a sample CloudEvent as event.json, then post it with the Svix headers your handler expects:

curl -X POST "https://your-app.example.com/webhooks/rtgs" \
  -H "Content-Type: application/json" \
  -H "svix-id: msg_2example00000000000000000" \
  -H "svix-timestamp: 1781000000" \
  -H "svix-signature: v1,<base64-signature>" \
  --data @event.json

To exercise the Svix signature check end to end, generate the svix-signature value with your signing secret using the Svix testing helpers. The RTGS.global signature can only be produced by RTGS.global, so verification of verificationmaterial is best tested against a notification delivered from a sandbox environment.

Where to go next​