Skip to main content
Every error raised by the Taliup PHP SDK is thrown as a Taliup\Sdk\Exceptions\ApiException. This includes failed API calls, invalid responses, and webhook signature verification failures. Wrapping your SDK calls in a try/catch block gives you full control over how your application responds to each failure scenario.

Catching exceptions

Use a standard try/catch block wherever you call the SDK:

ApiException methods

ApiException extends PHP’s built-in RuntimeException. The following methods are available for handling errors:

HTTP status codes

Use getStatusCode() to branch your error-handling logic by failure type:
The table below lists the status codes you are most likely to encounter:
A status code of 0 does not come from the Taliup API — it means the HTTP request never completed. This typically indicates a network outage, DNS failure, firewall rule, or a timeout value that is too low for your environment. Check your server’s outbound connectivity and consider increasing the timeout option when instantiating Client.

Validation errors

When the API returns 422, the getResponseBody() array often contains field-level detail you can use for debugging:

Webhook signature errors

Webhook::constructEvent() throws an ApiException with status code 401 and the message 'Webhook signature verification failed.' when the signature does not match:
A signature failure usually means one of the following:
  • The request did not originate from Taliup (potential spoofing attempt).
  • You read $_POST or called json_decode() before reading php://input, which altered the raw body.
  • The wrong secret key is set in the TALIUP_MERCHANT_SECRET_KEY environment variable.

Best practices

Log errors server-side

Always log getMessage(), getStatusCode(), and getResponseBody() to your server logs or error-tracking service. This gives you the context you need to diagnose issues without exposing sensitive data to users.

Never expose raw errors to users

Display a generic, friendly message to your customers. Raw API error messages can leak implementation details, field names, or configuration hints that an attacker could use.

Complete error-handling example