Two methods for defining asynchronous callbacks are supported -
Purchase success callbacks and webhooks.
Purchase success callbacks
Purchase success callbacks are defined by providing a target URL in the
success_callback field on
Purchase creation (see POST /purchases/). The system will generate a callback when:
skip_capture=falseis successfully paid;
skip_capture=trueis successfully captured (see POST /purchases//capture/);
Purchaseis successfully paid using a recurring token (see POST /purchases//charge/);
These callbacks pass a JSON-encoded
Purchase as their payload. The payload represents a snapshot of the state of the
Purchase when the event was created. The payload will include an
event_type field to indicate which specific event (see Event schema) triggered the callback.
The payload is signed using a company-wide key pair. You can obtain the public key with
GET /public_key/. See the
Authentication section below for more details.
For creating and modifying webhooks, see the Webhook CRUD API specification.
Webhook callback payloads are signed using a dedicated key pair. You can obtain the public key from
Webhook.public_key. See the Authentication section below for more details.
When a callback is not successfully delivered (received by the target server and responded to with a 200 series HTTP response code), the system will make up to 8 additional attempts at exponentially increasing intervals between attempts. No further delivery attempts will be made if the callback is not successfully delivered 36 hours after triggering.
Please note that due to the asynchronous nature of network requests, it is possible for a callback delivery confirmation (HTTP response with a 200 series status code) to not properly arrive from the callback’s target server. Therefore it is possible in case of severe network faults for the target server to receive a callback, respond to it with a 200 series HTTP status code and then receive the same callback after an interval.
Callback deliveries are guaranteed to be sequential to events triggered on their source objects. For example, when registering webhooks for both the
purchase.paid events, there will be no
purchase.paid callbacks for this
Purchase until all
purchase.created callbacks for this
Purchase are successfully delivered.