Transaction Webhooks
Payments is a webhook world
Last updated
Payments is a webhook world
Last updated
API calls are always asynchronous. However, when you call an API endpoint, you expect to get a response within a relatively short timeframe. In payment processing, a single call to an endpoint may invoke a chain of other API calls between the target and other payment processors.
Waiting for these calls to complete will require very long-lived requests that will bog down server resources on all the platforms involved. It can also cause timeout errors as certain servers can only hold a request pipeline open for fixed periods.
Popular solutions to this problem include:
Polling - You continually make requests at intervals for the status of the transaction.
Webhooks - You provide a URL we will call to update the transaction status once it is resolved.
It is obvious that webhooks provide a more efficient solution.
You can configure your webhook URL on the developer dashboard.
NOTE: Your webhook URL must be reachable on the open internet without authentication. Localhost URLs cannot be used directly as endpoints. However certain services may enable you to link localhost ports to an open address eg ngrok
.
IMPORTANT: Because your webhook endpoint is exposed to the internet without a security wall, we advise you to always verify the webhook event source.
Certain requests also allow you to provide a callback URL that should be called in case of the completion of a transaction. This means that both your callback URL and webhook
Webhook endpoints must be publicly accessible. This means you must verify that the call is from SwitchApp before giving value. One way to do this is to validate the x-switchapp-signature
header sent with every webhook event. The value of this header is a HMAC SHA512
signature of the event payload signed using your secret key. Below are samples of how to validate the signature: