Recieving Updates

Receiving Purchase and Deposit Updates (Hybrid Webhook + API)

This document provides best practices for receiving Purchase and Deposit updates from Inabit Terminal. It explains how to combine Webhooks (for instant notifications) with the GET API (for reconciliation and reliability).

Goal: A simple, reliable setup to receive purchase and deposit updates using both:

• Webhooks for instant notifications

• GET API backup for periodic reconciliation and gap-filling.

The hybrid approach is the recommended method for production.

1) Why Hybrid?

• Immediate updates: Webhooks deliver events as they happen (e.g. IncomingTransactionReceived, PurchaseInitiated ).

• Resilient: If a webhook is delayed, retried, or missed, the GET API fills the gap.

• Accurate: Regular API polling verifies totals, confirmations, and states.

2) Minimal Setup

Webhook push

• Inabit Terminal sends an HTTPS POST for each deposit or purchase event. (Refer to Webhooks)

• Merchant endpoint should:

• Validate JSON & schema.

• Respond with 2xx within 5s after basic checks.

• Enqueue the event for asynchronous processing (avoid heavy logic in the webhook).

• Retries: If no 200 response is received, Inabit retries delivery.

• Signature: Support for signing will be added in future. In the meantime, merchants can validate by cross-checking the event using the GET API by Purchase/Deposit ID endpoint.

GET API pull

• Poll events by timestamp (starting from the last processed event).

• Maintain a durable checkpoint (last handled timestamp).

• Recommended polling frequency: every 2–3 minutes.

• Use the last timestamp as the starting point and set the end time with ~1 minute delay to ensure no missed events.