Two webhooks
Download this API's OpenAPI YAML
Overview and usage
Two provides webhooks via a portal that allows you to self-manage your application's webhook subscriptions and related configuration options when receiving these webhooks. Please refer to the portal's Receiving webhooks documentation for more details about using the portal and how to consume webhook events.
Getting started
- Login to the Two Merchant Portal.
- Within the Two Merchant Portal, go to the "Integrations" page and press the "Manage webhook subscriptions" button. You should be directed to the webhooks portal.
- Once you are logged in to the webhooks portal, please refer to the webhook portal documentation for details on how to configure your subscriptions.
- In the webhooks portal, once you have configured an endpoint to receive webhooks, you can send test/example payloads to the endpoint by going to Endpoints, selecting one of your configured endpoints, selecting the Testing tab, choosing which event type to send and then hitting the Send Example button.
- Alternatively, you can use one of our simulation endpoints to emit webhooks matching one of the event type schemas. See details under schemas for each webhook.
Webhooks Postman Collection
To get started using the simulation endpoints and events that trigger webhooks, we have a downloadable Postman collection.
#¤ Environments
Testing
https://api.sandbox.two.inc
Production
TBC
Pre-requisites
- An API key to access our checkout API. You can get an API key (which you should keep protected) for your application from the Two Merchant Portal.
- An email address to receive invoices and similar notifications, such as credit notes (optional).
The simulation endpoints we provide to trigger certain webhooks are made for testing purposes only and are only available in our sandbox environment. There are some limitations with these and may not always provide fully accurate data in some edge cases.
Interpreting order reconciliation events
Order reconciliation events (event types with prefix order.reconciliation.) describe financial events related to
orders that are relevant to the buyer.
All order reconciliation events have an amount field in the payload, which can be summed over multiple events to
calculate the amount owed by buyers (a.k.a. the outstanding amount).
The outstanding amount can be calculated on different levels by grouping/filtering on other IDs carried in the order
reconciliation events, for instance:
- Grouping the sum by order ID yields outstanding amount for that order.
- Grouping by billing period ID yields the outstanding amount on a billing statement level.
Payment allocation events (order.reconciliation.payment_allocated.v1) describe the portion of a payment used to cover
an invoice. The payment sub-structure of the payload contains information on the actual payment itself. It may be
larger than a single allocation, and may show up on multiple allocation events if used to cover more than one invoice.