PUT
/
webhooks
/
{id}
curl --request PUT \
  --url https://gate.chip-in.asia/api/v1/webhooks/{id}/ \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "title": "<string>",
  "all_events": false,
  "public_key": "<string>",
  "events": [
    "purchase.created"
  ],
  "callback": "<string>"
}'
{
  "type": "<string>",
  "id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
  "created_on": 1619740800,
  "updated_on": 1619740800,
  "title": "<string>",
  "all_events": false,
  "public_key": "-----BEGIN PUBLIC KEY-----\nMIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA6gLlBKxCB5dxPJbinCzl\nhOfKSgQtOWQQBxmnWIkEVUbqhpnqr3xNYiAvDyMUxYUwuzN44eHO+mR9MZWcSx3c\nbXmKa3gsOzR6GdcOxMGaVxvfje+fujCAlCtO1BP+A9/FS3KcPgCYG1wtAPwA5IAf\nHylL3TsUVIJQFBgiBr6N4Bgapr9eloaFfeYIBRsXmxPKAMJivqxYpLh0V3N4ZFd5\nTGqSEAa4b1ULDr6p0sB2L3QikTdsF0zp03zNceKA6fXDOzD0xWtg9buXvyKwePK4\nM2kcnWBNfsWghrdg0fG3O9bmkaS1oEXydrmJfuiI8h6a64J/1nzooi2yLC9D6Ta0\nS63bbuAHymnQtiNuV7Ixp6IoTGFaS88aTiHaP8rdyWV8JTDFx0qeDzyaGWiYGwEF\nmj/buHCEcRhoajbGkPhYA4YEdn4jy1wZhEr2OMdBPM7mPPI0Hy3hcNJVMVVlrpHe\nIltQATpjlNaJMlRPjbcaiW7dsO3BuF9ZOMGksSOnyYm/AgMBAAE=\n-----END PUBLIC KEY-----",
  "events": [
    "purchase.created"
  ],
  "callback": "<string>"
}

Authorizations

​
Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path Parameters

​
id
string
required

Object ID (UUID)

Body

application/json

Defines a webhook rule to an external server. The callback URL will receive a POST request with the related object's (e.g. Purchase for purchase.* webhooks) data in body when any of the events (see the description of events field below) it is configured to listen for are triggered. The payload object will additionally include an "event_type" field to indicate which event type (see the Webhook.events field) triggered the webhook.

Note that, as well as with the rest of dataset, test and live Webhooks are separate; test webhooks will not handle events caused by live Purchases, and vice-versa.

​
title
string
required

Arbitrary title of webhook

Maximum length: 100
​
events
enum<string>[]
required

List of events to trigger webhook callbacks for. Either this or all_events is required.

Available event types and when they are emitted:

purchase.created: Emitted when a Purchase is created. This happens as a result of POST /purchases/ request executed successfully or of any of the Billing API methods, including scheduled billing run by a BillingTemplate with is_subscription = true. Purchase.status will be == created in the received payload.

purchase.paid: Emitted when a Purchase is paid for. Purchase.status will be == paid. Happens when a payform is submitted (for a Purchase having skip_capture == false) and a successful payment is done by the payer or in case of /capture/ or /charge/ API requests executed successfully.

purchase.payment_failure: Emitted when payer submits a payment using the payform, but it doesn't complete successfully (e.g. because payer's account balance is insufficient). Purchase.status will be == error.

purchase.pending_execute: Emitted when transaction execution takes longer than expected on the acquirer side. See pending_execute Purchase status. When transaction becomes finalized, a purchase.paid, purchase.hold or purchase.payment_failed callback will be emitted.

purchase.pending_charge: Emitted when transaction execution takes longer than expected on the acquirer side. See pending_charge Purchase status. When transaction becomes finalized, a purchase.paid or purchase.payment_failed callback will be emitted.

purchase.cancelled: Emitted once POST /purchases/{id}/cancel/ request succeeds. It won't be possible to pay for the related Purchase after that. Purchase.status will be == cancelled.

purchase.hold: Emitted when a Purchase having skip_capture == true has its payform submitted and "payment" performed successfully. The specified amount of funds will be placed on hold. Purchase.status will be == hold.

purchase.captured: Emitted when the POST /purchases/{id}/capture/ request for a Purchase that previously had the status of hold succeeds. Purchase.status will be == paid.

purchase.pending_capture: Emitted when transaction execution takes longer than expected on the acquirer side. See pending_capture Purchase status. When transaction becomes finalized, a purchase.captured callback will be emitted.

purchase.released: Emitted when the POST /purchases/{id}/release/ request for a Purchase that previously had the status of hold succeeds. Funds reserved will be released with no payment performed. Purchase.status will be == released.

purchase.pending_release: Emitted when transaction execution takes longer than expected on the acquirer side. See pending_release Purchase status. When transaction becomes finalized, a purchase.released callback will be emitted.

purchase.preauthorized: Emitted when preauthorization scenario (see description for the Purchase.skip_capture field) is executed successfully. Purchase will have a status of preauthorized.

purchase.recurring_token_deleted: Emitted when the POST /purchases/{id}/delete_recurring_token/ request is executed successfully, deleting the recurring token associated with a Purchase. Purchase status will be the same as it were prior to this event.

purchase.pending_recurring_token_delete: Emitted when token deletion takes longer than expected on the acquirer side. When operation is finalized, a purchase.recurring_token_deleted callback will be emitted.

purchase.subscription_charge_failure: Emitted when an attempt to charge some Client's subscription-generated Purchase, using the token (e.g. card) they saved for their subscription, fails. Can only be emitted for a Purchase spawned from a BillingTemplate having is_subscription == true. Usually means the system can't charge the subscriber Client's card because e.g. their account balance is insufficient or card is expired, hence an invoice to be paid manually will be automatically mailed to them. Purchase.status in the returned payload will be == sent.

purchase.pending_refund: Emitted when refund transaction execution takes longer than expected on the acquirer side. See pending_refund Purchase status. When refund becomes finalized, a payment.refunded callback will ne emitted.

payment.refunded: Emitted when a Purchase is refunded (as a result of POST /purchases/{id}/capture/ request done successfully or action performed in company's frontoffice system). The returned data will be a Payment object generated as a result of this action. A link to the original Purchase (that will have a status of refunded) will be present in the related_to field of this Payment.

billing_template_client.subscription_billing_cancelled: Emitted when a subscriber represented by this event's related BillingTemplateClient cancels their subscription using an email link available in the receipts he receives. The respective BillingTemplateClient will have its status set to subscription_paused as a result.

payout.pending: Emitted when Payout execution has been initiated and is currently processing.

payout.failed: Emitted when a Payout processing was completed with an error. Payout.status will be == error. Note that payouts can spend up to 3-5 days (depending on the payout provider) in processing after being initiated.

payout.success: Emitted when a Payout is successfully processed. Payout.status will be == success. Note that payouts can spend up to 3-5 days (depending on the payout provider) in processing after being initiated.

Available options:
purchase.created,
purchase.paid,
purchase.payment_failure,
purchase.pending_execute,
purchase.pending_charge,
purchase.cancelled,
purchase.hold,
purchase.captured,
purchase.pending_capture,
purchase.released,
purchase.pending_release,
purchase.preauthorized,
purchase.pending_recurring_token_delete,
purchase.recurring_token_deleted,
purchase.subscription_charge_failure,
purchase.pending_refund,
payment.refunded,
billing_template_client.subscription_billing_cancelled,
payout.pending,
payout.failed,
payout.success
​
callback
string
required
Maximum length: 500
​
all_events
boolean
default:false

Specifies this webhook should trigger on all event types. Either this or events is required.

​
public_key
string

PEM-encoded RSA public key for authenticating webhook or callback payloads

Response

200
application/json
OK

Defines a webhook rule to an external server. The callback URL will receive a POST request with the related object's (e.g. Purchase for purchase.* webhooks) data in body when any of the events (see the description of events field below) it is configured to listen for are triggered. The payload object will additionally include an "event_type" field to indicate which event type (see the Webhook.events field) triggered the webhook.

Note that, as well as with the rest of dataset, test and live Webhooks are separate; test webhooks will not handle events caused by live Purchases, and vice-versa.

​
title
string
required

Arbitrary title of webhook

Maximum length: 100
​
events
enum<string>[]
required

List of events to trigger webhook callbacks for. Either this or all_events is required.

Available event types and when they are emitted:

purchase.created: Emitted when a Purchase is created. This happens as a result of POST /purchases/ request executed successfully or of any of the Billing API methods, including scheduled billing run by a BillingTemplate with is_subscription = true. Purchase.status will be == created in the received payload.

purchase.paid: Emitted when a Purchase is paid for. Purchase.status will be == paid. Happens when a payform is submitted (for a Purchase having skip_capture == false) and a successful payment is done by the payer or in case of /capture/ or /charge/ API requests executed successfully.

purchase.payment_failure: Emitted when payer submits a payment using the payform, but it doesn't complete successfully (e.g. because payer's account balance is insufficient). Purchase.status will be == error.

purchase.pending_execute: Emitted when transaction execution takes longer than expected on the acquirer side. See pending_execute Purchase status. When transaction becomes finalized, a purchase.paid, purchase.hold or purchase.payment_failed callback will be emitted.

purchase.pending_charge: Emitted when transaction execution takes longer than expected on the acquirer side. See pending_charge Purchase status. When transaction becomes finalized, a purchase.paid or purchase.payment_failed callback will be emitted.

purchase.cancelled: Emitted once POST /purchases/{id}/cancel/ request succeeds. It won't be possible to pay for the related Purchase after that. Purchase.status will be == cancelled.

purchase.hold: Emitted when a Purchase having skip_capture == true has its payform submitted and "payment" performed successfully. The specified amount of funds will be placed on hold. Purchase.status will be == hold.

purchase.captured: Emitted when the POST /purchases/{id}/capture/ request for a Purchase that previously had the status of hold succeeds. Purchase.status will be == paid.

purchase.pending_capture: Emitted when transaction execution takes longer than expected on the acquirer side. See pending_capture Purchase status. When transaction becomes finalized, a purchase.captured callback will be emitted.

purchase.released: Emitted when the POST /purchases/{id}/release/ request for a Purchase that previously had the status of hold succeeds. Funds reserved will be released with no payment performed. Purchase.status will be == released.

purchase.pending_release: Emitted when transaction execution takes longer than expected on the acquirer side. See pending_release Purchase status. When transaction becomes finalized, a purchase.released callback will be emitted.

purchase.preauthorized: Emitted when preauthorization scenario (see description for the Purchase.skip_capture field) is executed successfully. Purchase will have a status of preauthorized.

purchase.recurring_token_deleted: Emitted when the POST /purchases/{id}/delete_recurring_token/ request is executed successfully, deleting the recurring token associated with a Purchase. Purchase status will be the same as it were prior to this event.

purchase.pending_recurring_token_delete: Emitted when token deletion takes longer than expected on the acquirer side. When operation is finalized, a purchase.recurring_token_deleted callback will be emitted.

purchase.subscription_charge_failure: Emitted when an attempt to charge some Client's subscription-generated Purchase, using the token (e.g. card) they saved for their subscription, fails. Can only be emitted for a Purchase spawned from a BillingTemplate having is_subscription == true. Usually means the system can't charge the subscriber Client's card because e.g. their account balance is insufficient or card is expired, hence an invoice to be paid manually will be automatically mailed to them. Purchase.status in the returned payload will be == sent.

purchase.pending_refund: Emitted when refund transaction execution takes longer than expected on the acquirer side. See pending_refund Purchase status. When refund becomes finalized, a payment.refunded callback will ne emitted.

payment.refunded: Emitted when a Purchase is refunded (as a result of POST /purchases/{id}/capture/ request done successfully or action performed in company's frontoffice system). The returned data will be a Payment object generated as a result of this action. A link to the original Purchase (that will have a status of refunded) will be present in the related_to field of this Payment.

billing_template_client.subscription_billing_cancelled: Emitted when a subscriber represented by this event's related BillingTemplateClient cancels their subscription using an email link available in the receipts he receives. The respective BillingTemplateClient will have its status set to subscription_paused as a result.

payout.pending: Emitted when Payout execution has been initiated and is currently processing.

payout.failed: Emitted when a Payout processing was completed with an error. Payout.status will be == error. Note that payouts can spend up to 3-5 days (depending on the payout provider) in processing after being initiated.

payout.success: Emitted when a Payout is successfully processed. Payout.status will be == success. Note that payouts can spend up to 3-5 days (depending on the payout provider) in processing after being initiated.

Available options:
purchase.created,
purchase.paid,
purchase.payment_failure,
purchase.pending_execute,
purchase.pending_charge,
purchase.cancelled,
purchase.hold,
purchase.captured,
purchase.pending_capture,
purchase.released,
purchase.pending_release,
purchase.preauthorized,
purchase.pending_recurring_token_delete,
purchase.recurring_token_deleted,
purchase.subscription_charge_failure,
purchase.pending_refund,
payment.refunded,
billing_template_client.subscription_billing_cancelled,
payout.pending,
payout.failed,
payout.success
​
callback
string
required
Maximum length: 500
​
type
string

Object type identifier

​
id
string
​
created_on
integer

Object creation time

Example:

1619740800

​
updated_on
integer

Object last modification time

Example:

1619740800

​
all_events
boolean
default:false

Specifies this webhook should trigger on all event types. Either this or events is required.

​
public_key
string

PEM-encoded RSA public key for authenticating webhook or callback payloads

Example:

"-----BEGIN PUBLIC KEY-----\nMIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA6gLlBKxCB5dxPJbinCzl\nhOfKSgQtOWQQBxmnWIkEVUbqhpnqr3xNYiAvDyMUxYUwuzN44eHO+mR9MZWcSx3c\nbXmKa3gsOzR6GdcOxMGaVxvfje+fujCAlCtO1BP+A9/FS3KcPgCYG1wtAPwA5IAf\nHylL3TsUVIJQFBgiBr6N4Bgapr9eloaFfeYIBRsXmxPKAMJivqxYpLh0V3N4ZFd5\nTGqSEAa4b1ULDr6p0sB2L3QikTdsF0zp03zNceKA6fXDOzD0xWtg9buXvyKwePK4\nM2kcnWBNfsWghrdg0fG3O9bmkaS1oEXydrmJfuiI8h6a64J/1nzooi2yLC9D6Ta0\nS63bbuAHymnQtiNuV7Ixp6IoTGFaS88aTiHaP8rdyWV8JTDFx0qeDzyaGWiYGwEF\nmj/buHCEcRhoajbGkPhYA4YEdn4jy1wZhEr2OMdBPM7mPPI0Hy3hcNJVMVVlrpHe\nIltQATpjlNaJMlRPjbcaiW7dsO3BuF9ZOMGksSOnyYm/AgMBAAE=\n-----END PUBLIC KEY-----"