Use of legacy endpoints for new integrations is discouraged where alternative endpoints have been provided.
Legacy Payment Requests
Centrapay Payment Requests are serviced via two sets of endpoints; the "next" version (documented Payment Requests ) and the "legacy" version (documented on this page). These endpoints are .
Payment Request Model
Attributes
Payment Options Model
Attributes
-
ledger
-
amount
-
account
-
methods
Paid By Model
Attributes
-
transactionId
-
amount
Ledger and Authorization Values
The "ledger" parameter indicates which payment option has been selected to pay the payment request. The selected payment option must be one of the options available for the payment request as per the payments
array in the requests.create and requests.info responses.
The table below lists the possible ledger and authorization param values. The asset type is the value used to configure the merchant. The ledger param value is returned with the payment request info as payments[].ledger
.
Asset Type | Ledger Param Value | Authorization Param Value |
---|---|---|
centrapay.nzd.main | centrapay.nzd.main | Centrapay wallet id |
centrapay.nzd.test | centrapay.nzd.test | Centrapay wallet id |
bitcoin.main | g.crypto.bitcoin.mainnet | Bitcoin transaction id |
Create a Payment Request
This endpoint allows you to create a Payment Request.
Attributes
-
amount
-
asset
-
merchantId
-
clientId
-
description
-
externalReference
-
notifyUrl
-
patronCode
-
paymentExpirySeconds
-
terminalId
-
deviceId
Errors
-
CHECKSUM_FAILED
-
PATRON_CODE_INVALID
-
MERCHANT_CONFIGURATION_NOT_FOUND
-
NO_AVAILABLE_PAYMENT_OPTIONS
Get a Payment Request
This endpoint allows you to receive Payment Request information.
Attributes
-
requestId
Pay a Payment Request <
This endpoint allows you to pay a Payment Request.
Attributes
-
requestId
-
ledger
-
authorization
Errors
-
REQUEST_EXPIRED
-
REQUEST_PAID
-
REQUEST_CANCELLED
-
INVALID_ASSET_TYPE
-
INACTIVE_ASSET
-
INVALID_MERCHANT_CONFIG
-
QUOTA_EXCEEDED
-
INSUFFICIENT_ASSET_VALUE
-
ASSET_REDEMPTION_DENIED
Cancel a Payment Request
This endpoint allows you to cancel a Payment Request.
Attributes
-
requestId
Errors
-
REQUEST_NOT_FOUND
-
REQUEST_EXPIRED
-
REQUEST_PAID
Void a Payment Request
This endpoint allows you to void a Payment Request.
Attributes
-
requestId
Errors
-
REQUEST_NOT_FOUND
-
REQUEST_EXPIRED
-
REQUEST_PAID
Voiding a payment request can cause it to be cancelled or refunded. Therefore, this endpoint can give the same error responses as requests.cancel and transactions.refund . After 24 hours voiding a payment request will be disallowed, however a refund can still be made against the payment request if it has been paid successfully.
Refund a Transaction
Refunding a transaction can be done with or without an external reference.
Refund without external reference
If you refund a transaction without providing an external reference, you will get a successful response for the first request and then an ALREADY_REFUNDED
message for any refund requests that follow for the same transaction, unless an external reference is provided.
Refund with external reference
If you provide an external reference then a transaction can be refunded multiple times provided that the external reference is unique for each refund request. When a duplicate external reference is provided when attempting to refund the same transaction we return a successful response if the amount of the request is the same both times but do not process another refund, this is because we assume it to be a repeat request. If the amount is different you will get a REPEAT_REFERENCE
error message.
Refund a Pre Auth Payment Request with Confirmations
The legacy refund endpoint cannot be used to refund Pre Auth Payment Requests with Confirmations. Please use the current refund endpoint instead.
Attributes
-
transactionId
-
amount
-
externalReference
Errors
Attributes
-
ALREADY_REFUNDED
-
INVALID_AMOUNT
-
REPEAT_REFERENCE
-
PARTIAL_REFUNDS_NOT_ALLOWED
-
INACTIVE_ASSET
-
REFUND_NOT_SUPPORTED
-
REFUND_WINDOW_EXCEEDED
-
REFUND_DECLINED
Webhooks
Webhook notifications are sent for significant Payment life-cycle events. The Webhook endpoint is notified by sending an HTTP POST request to the notifyUrl
defined in the Payment Request.
Life-cycle Events That Trigger Webhooks
The supported event types that will be notified to the Payment Requests webhook and the associated "transactionType" value that will be sent in the payload are:
Event Type | Value of "transactionType" |
---|---|
Payment Request Cancelled | CANCELLED |
Payment Request Expired | EXPIRED |
Transaction Completed | PURCHASE |
Transaction Refunded | REFUND |
Payment Request Cancelled
A payment request can be cancelled by either calling the requests.cancel or requests.void endpoint before a request has been paid successfully. When a request has been cancelled we send a JWT that when decoded matches the Payment Request Cancelled example in the Decoded Webhook JWT Examples section below.
Payment Request Expired
A payment request expires two minutes after being created if it hasn't been cancelled, or paid. When a request has expired we send a JWT that when decoded matches the Payment Request Cancelled example in the Decoded Webhook JWT Examples section below with the transactionType
set to EXPIRED.
Transaction Completed
A transaction is considered complete when requests.pay is called with parameters that satisfy a payment request and the request has been paid successfully. When a transaction has been completed we send a JWT that when decoded matches the Transaction Completed example in the Decoded Webhook JWT Examples section below.
Transaction Refunded
A transaction can be refunded one to many times and each time a transaction has been refunded successfully we notify the webhook associated with the original payment request. A transaction can be refunded when transactions.refund has been called for a partial or full refund, or when requests.void is called for a request that has been paid. When a transaction has been refunded we send a JWT that when decoded matches the Transaction Completed example in the Decoded Webhook JWT Examples section below but with transactionType
set to REFUND.
Webhook Payload
The body of the webhook is a JSON document with the following format:
The decoded JWT will contain a transaction
property with a transactionType
that indicates the event type. Depending on the type of event, the payload will also contain additional details about the transaction and payment request. For example:
Webhook Payload Fields
Property | Description |
---|---|
transactionId | Id of the transaction |
transactionType | Indicates which event triggered the notification message |
state | Current state of the transaction |
ledger | The ledger at which the authorization was processed |
amount | Transaction amount in the lowest denomination available |
createdAt | Timestamp at which the request was created |
updatedAt | Timestamp at which the request was updated |
type | The payment type used by the issuer to reconcile settlement |
request | Request object, see details at [requests.info][] |
authCode | Authorization code used to settle this transaction |
Webhook JWT Validation
A webhook JWT can be validated by checking the signature against the Centrapay Webhook public key: