The example below shows the integrator polling for the Payment Request, this is not needed for eCommerce as the integrator will be informed when the authorization has completed.
Guides
Requesting Pre Auth
Centrapay’s Pre Auth extension allows a patron to authorize payment up to a limit when the actual payment amount is not yet known.
Restrictions
Pre Auth payments are not supported in all cases.
- Not all asset types support Pre Auth - Payment options for Asset Types that do not support Pre Auth will be excluded when a Payment Request is created with the
preAuth
flag. - Pre Auth is incompatible with Multi-Asset payments - Only one asset type can be authorized for a Pre Auth.
Pre Auth Flow
Pre Auth payments go through an orthogonal payment flow compared to Centrapay’s standard payment flow.
See also: Requesting Payment .
sequenceDiagram autonumber participant Patron participant Integrator participant Centrapay note over Patron, Integrator: Connect with Patron Integrator->>Centrapay: Create Authorization note over Integrator: Poll for Payment Confirmation note over Integrator: ✅ Display Successful Authorization note over Integrator, Centrapay: ⏱️ Some time later.. loop 0..Many (Up to Authorized Amount) Integrator->>Centrapay: Make Confirmations Against Authorized Funds end Integrator->>Centrapay: Release Remaining Authorized Funds
- The Integrator places a hold on funds by creating an Authorization.
- The Integrator draws down on authorized funds by making Confirmations against the authorization when the purchase is ready to be fulfilled.
- The Integrator releases any remaining funds that have not been confirmed back to the Patron.
Authorize
An authorization is created when the Payment Request is created with the preAuth
flag while Requesting Payment .
Once the authorization is successful, the Payment Request preAuthStatus
is set to authorized
.
Confirm
Merchants can draw down on authorized funds by making one or more confirmations against an authorized amount. Confirmations must be made with an idempotencyKey
in order to prevent merchants from drawing down on authorized funds twice.
Confirmations against authorized funds have limits:
Authorizations must be followed up with a confirmation - otherwise, the authorization will expire and the funds will be returned to the asset holder.
The
preAuthExpiry
may be adjusted to match pre-determined expiry rules set by the asset provider.Multiple confirmations can be performed against an authorization but the total value cannot exceed the original authorized value.
Release
Authorized funds that have not been confirmed can optionally be released so that the asset holder is granted access to their remaining funds without needing to wait for the authorization to expire. Once releasing any remaining authorized funds is successful, the Payment Request preAuthStatus
is set to released
.
Authorizations automatically expire after 3 months. Any unreleased funds are subsequently released to the Patron.
Refund
Refunds can be made against authorizations, confirmations, released authorizations and expired authorizations.
Refunds made against confirmations must include the confirmationIdempotencyKey
field that is the same as the idempotencyKey
used for original confirmation.
Void
Voiding a Payment Request will cancel a Payment Request and trigger any refunds necessary. This operation is useful if the Integrator needs to back out of a transaction due to a network error for example. Voiding can only be used up to 24 hours after the Payment Request was created.