The Prysym APIs are designed to enable clients to make and receive payments globally by quickly and easily integrating into their native systems without knowing how arcane payment systems work globally or even having many details about the recipient. We’ve integrated a combination of more common methods, new services as well novel techniques pioneered by the company representing the most diverse and ever expanding final-mile payment options possible. This enables the client to make an instant payment to anyone, anywhere and enables the recipient to decide the best way to access their money. (The above is subject to sanctions and regulated entity approvals).

To make API calls, include the bearer token in the Authorization header with the Bearer authentication scheme.

The value is Bearer <Your-Secret-Key>.

The URL to the API service is either:

• UAT. https://api.uat.prysym.com

• Live. https://api.prysym.com

APIs use the Status-Line part of an HTTP response message to inform clients of their request’s overarching result.

HTTP defines over 40 standard status codes that can be used to convey the results of a client’s request. The status codes are divided into the five categories presented here:

• 1xx: Informational - Communicates transfer protocol-level information
• 2xx: Success - Indicates that the client’s request was accepted successfully.
• 3xx: Redirection - Indicates that the client must take some additional action in order to complete their request.
• 4xx: Client Error - This category of error status codes points the finger at clients.
• 5xx: Server Error - The server takes responsibility for these error status codes.

Payment Instruments

Prysym's Acquiring functionality

Prysym's Transactions functionality allows you to manage transactions.

Prysym sends webhooks to notify your systems of events as they happen — card transactions, settlements, chargebacks and merchant onboarding updates. Each event is delivered as an HTTP POST with a JSON body to the URL registered on your subscription. The destination must be an https URL on a publicly resolvable host; plain http, private ranges and loopback addresses are rejected when the subscription is created or updated.

Delivery is at-least-once: the same event may arrive more than once, so treat event_id as an idempotency key. Respond with any 2xx status to acknowledge receipt. A timeout, a 5xx, a 408 or a 429 is retried; any other 4xx is treated as a permanent rejection and the delivery is dead-lettered without a second attempt. The event id is also sent in a Webhook-Id header, so you can discard a redelivery without parsing the body.

Create a subscription with the Create Webhook Subscription endpoint, supplying the destination url, a secret_key used to sign deliveries, and optionally the event_types you want (omit to receive all). Events begin flowing immediately; no further setup is required.

Every delivery is signed so you can confirm it came from Prysym and was not altered in transit. The signature is sent in the x-webhook-signature header and is computed with HMAC-SHA256 over the timestamp and the raw request body, keyed with your subscription secret.

The value that is signed is "{t}.{raw_body}". The leading timestamp binds the signature to a point in time so you can reject stale or replayed requests. During a secret rotation the header carries more than one v1= signature (one per active secret); accept the delivery if any of them matches.

Step 4 is the only part that has to be exact, so it is the only part shown here. Each snippet takes four values and produces the same Base64 signature; how you parse the header, apply your tolerance window and reject a bad delivery is up to you.

To change a subscription's secret without missing deliveries, call Rotate Secret with the new value. Prysym then signs each delivery with both the old and new secrets (two v1= signatures), so consumers on either side of your deployment can verify. Once every consumer has the new secret, call Complete Rotation to drop the old one.

A retryable failure (a timeout, a 5xx, a 408 or a 429) is retried automatically with exponential backoff and jitter: up to 12 attempts, starting at 30 seconds and doubling to a 6 hour ceiling, each delay varied by up to 20%. Any other 4xx is permanent and is dead-lettered on the first attempt, because a rejected payload will be rejected again. After the maximum number of attempts the delivery is moved to a dead-letter state and is no longer retried automatically. Pausing a subscription (active false) stops new events being queued for it, but deliveries already queued are still attempted; deleting the subscription stops those too.

Inspect deliveries — including the dead-letter queue — with the List Deliveries endpoint, filtering on status (for example, ["DEAD"]). Re-queue an individual delivery with Retry Delivery. Delivered records are kept for 365 days and then purged; dead-lettered ones are kept until you act on them.

Each sample below is the full delivered body: the envelope wrapping a type-specific event_body.