Skip to main content

Webhook Signature Validation

To ensure the security and integrity of webhook notifications, Ripio signs the request payload using the ECDSA (Elliptic Curve Digital Signature Algorithm) with the P-256 curve. This allows you to verify that the webhook payload was sent by Ripio and has not been tampered with during transmission.

Overview of Signature Validation

Webhook requests from Ripio will include an X-Signature-Ecdsa-Sha256 header. This header contains the ECDSA signature of the request payload. You will need to use Ripio’s public key to verify this signature.

Validating the Signature: Step-by-Step Guide

  1. Retrieve the Signature Header: Extract the value of the X-Signature-Ecdsa-Sha256 header from the incoming webhook request. The signature is Base64 encoded.
  2. Extract the Raw Payload: Get the raw JSON payload from the body of the webhook request. It is crucial to use the raw, unmodified payload as it was received.
  3. Verify the Signature: Using Ripio’s public key for the P-256 curve, verify the signature against the raw payload. If the signature is valid, the webhook is authentic.

Important Notes for Signature Validation

  • Exact Payload: Ensure that the payload used for verification is exactly as it was sent by Ripio. Any modification will cause the verification to fail. The JSON payload must be serialized into a compact string, with no whitespace after separators (e.g., {"key":"value"} instead of {"key": "value"}).
  • Secure Public Key Storage: Store Ripio’s public key securely.
  • Reject Invalid Requests: Always reject requests with missing or invalid signatures.

Webhook Events

For details on specific webhook events and their payload structures, please refer to the following pages:

Identifying a Message

Every message carries a message_id, unique to it, alongside event_type, issue_datetime and payload:
This is the value to key your idempotency on. A retry re-sends the very same body, and the endpoints below return that same body unchanged, so a message you have already processed is recognizable by its message_id no matter how it reaches you. Note that payload.id is not enough on its own: a single operation is notified more than once as it advances, and each of those notifications is a different message. If your account has more than one webhook configured, each one receives its own copy of every event, and each copy is a message of its own with its own message_id.

Retrieving Past Messages

Every message issued for your account is kept, and can be read later through the List IPN Messages endpoint, or one at a time with Retrieve IPN Message. Each one comes back exactly as it was delivered. This is what to reach for when a notification was missed because your endpoint was unavailable, or when you need to reconcile what Ripio sent against what you processed.

Recovering after an outage

A message your endpoint never acknowledged with a 2xx stays PENDING, whether it is still being retried or has already run out of retries. So the messages you missed are:
Read the pages in ascending id order, as above: new messages keep arriving while you page through, and ascending order leaves them at the end instead of shifting what you have not read yet. Then discard by message_id whatever you had already processed, and handle the rest. To reconcile a window rather than a failure, filter by date instead — date_gte and date_lte — and compare against what you have on your side.

Configuring Your Webhook Endpoint

To receive webhook notifications, you need to configure a publicly accessible HTTPS URL endpoint in your Ripio partner settings. Ripio will send POST requests to this URL with a JSON payload. Key considerations for your endpoint:
  • HTTPS: Your endpoint URL must use HTTPS.
  • Respond Quickly: Your endpoint should acknowledge receipt of the webhook by returning a 2xx HTTP status code (e.g., 200 OK or 202 Accepted) as quickly as possible, ideally within 10 seconds as per Ripio’s guidelines.
  • Asynchronous Processing: For any time-consuming processing of the webhook data, perform it asynchronously (e.g., using a message queue) to ensure your endpoint responds promptly.
  • Idempotency: Design your webhook handler to be idempotent. This means that processing the same event multiple times should not result in duplicated actions or inconsistent state, as network issues or retries might cause a webhook to be delivered more than once.
For specific instructions on configuring your webhook URL within your Ripio account, please reach out to the Ripio technical team.

Basic Endpoint Implementation Examples

Here are basic examples of how you might set up an endpoint to receive webhooks and validate ECDSA signatures.

Python (Flask Example)

Node.js (Express Example)