Skip to main content
Vestrapay does not publish an official SDK or client library at the moment. The API is small and uses plain JSON over HTTPS, so any HTTP client works. This page gives you tested patterns for the pieces every integration needs: a thin client, safe error handling, verification and webhook signature checking.
When an official SDK ships, it will be announced here and on vestrapay.com. Code written against the raw API will keep working.

Configuration

Read two values from the environment and nothing else. Switching from sandbox to live then means changing configuration, not code. The same secret key verifies webhook signatures; see Webhooks.

A thin client

The client below sends the secret key, sets a timeout, unwraps the envelope and raises a typed error that carries the error code and the request ID. It is deliberately small. Copy it, then add logging and metrics for your stack.

Initialise

Use the client to create a payment. The reference is generated by Vestrapay, so you save it after the call returns.
Initialise is not idempotent. Every successful call creates a new transaction with a new reference. If a call times out, you cannot know whether a transaction was created. It is safe to initialise again, because an unpaid transaction simply expires, but make sure only the reference you finally redirect the customer to is stored on the order.

Verify and fulfil once

This pattern combines verification with idempotent fulfilment. It is the one to copy for both your webhook handler and your callback page.
Compare amounts as strings, or as decimals. Do not parse them to binary floating point. If your records store “250.5”, normalise to two decimal places before comparing with “250.50”.

Verify a webhook signature

Signature checking needs the raw request body, so it is covered with the webhook payload and retry behaviour on the Webhooks page, with the same three languages.

Handling errors well

Always log the X-Request-Id response header with the error code. See Errors.