In this section, you'll find everything you need to manage the various entry points your application will receive during and after an Axepta BNP Paribas Online payment.
You'll learn:
- Which URLs to transmit when creating a payment,
- The order in which they are called,
- How to interpret the returned information,
- How to verify the actual status of a transaction,
- How to manage webhooks
1. Provide URLs : return, cancel, webhook
When initializing the payment, you must provide a URLs object:
urls{
"return":"https://myProcessingServer.net/myApi/success.php?transId=95330876-67ae-4949-a11c-b9a29257831b",
"cancel":"https://myProcessingServer.net/myApi/cancel.php?transId=95330876-67ae-4949-a11c-b9a29257831b",
"webhook":"https://myBackOfficeServer.net/webhook.php"
}
- return = redirection when the customer clicks the validation button at the end of payment
- cancel = redirection if the customer cancels
- webhook = asynchronous and guaranteed notification, regardless of the customer's action
2. Return URL & Cancel URL
One of these two URLs (return or cancel) will be called at the end of transaction processing to:
- Redirect the customer to the merchant's site at the end of the transaction
- Inform the merchant of the transaction status: whether it was validated or not
- Return the unique transaction identifier payId generated by Axepta Online to the merchant's back office
When either of these URLs is called, Axepta BNP Paribas Online automatically adds the parameter: PayId=<paymentId generated by Axepta> - see Integration recommendation
Add a unique identifier from your system to your URLs to link the response to your order.
Example of URL called during customer payment validation:
- en vert, the URL passed during payment initialization, with the transId added to link the response to a merchant ID.
- en rouge, the PayId parameter added by the server.
https://myProcessingServer.net/myApi/success.php?transId=95330876-67ae-4949-a11c-b9a29257831b&PayId=b6eae9b16e3343fa90da39d4ee7bf4ad
What to Do When You Receive This Call?
When one of these URLs is called:
Retrieve the PayId parameter.
Call the API to get the actual transaction status: GET /payments/getByPayId/{payId} - Retrieve payment details by Payment ID
- Update your order based on the status and responseCode.
Important Fields in the API Response
- Amount: value, capturedValue, refundedValue
- Identifiers: payId, transId, xId, refNr
- Status: status = AUTHORIZED, CAPTURED, FAILED, etc.
- Result:
- responseCode = "00000000" if successful
- responseDescription = text message
Example Response
{
"amount":{
"value":126,
"currency":"EUR",
"capturedValue":0,
"refundedValue":0
},
"payId":"91a6299a704147bf934aabd79fd1dc5d",
"merchantId":"MY_MERCHANT_ID",
"transId":"Trans361039",
"xId":"b55e68b7e4644a90836ae31effe1fc60",
"refNr":"refNb77254",
"status":"AUTHORIZED",
"responseCode":"00000000",
"responseDescription":"Transaction successful",
"paymentMethods":{
"type":"CARD"
}
}
3. Webhook
The Webhook notification is the only reliable way to be informed of transaction completion. It is essential for the merchant site to process requests received at the Webhook URL.
This notification is sent even if the customer:
- Closes their browser,
- Loses connection,
- Doesn't return to your site.
When is it sent?
At the end of each asynchronous payment processing.
What you need to do
- Read the JSON payload
- Identify the transaction via payId or transId
- Update your system
- Respond with a 200 OK status code
Important:
Never trigger order finalization based solely on the Return URL.
Always use the webhook as the reliable source of information.
Webhook Structure
Provided Fields
- merchantId
- payId
- transId
- xId
- refNr
- status (AUTHORIZED, FAILED, etc.)
- responseCode / responseDescription
- amount
- paymentMethods
- creationDate (UTC)
- channel (ECOM, MOTO, Pay By Link…)
Example
{
"merchantId": "YOUR_MERCHANT_ID",
"payId": "91a6299a704147bf934aabd79fd1dc5d",
"transId": "Trans361039",
"xid": "b55e68b7e4644a90836ae31effe1fc60",
"refNr": "refNb77254",
"status": "AUTHORIZED",
"responseCode": "00000000",
"responseDescription": "Transaction successful",
"amount": {
"value": 126,
"currency": "EUR"
},
"paymentMethods": {
"type": "CARD"
},
"creationDate": "2025-10-30T11:27:57Z",
"channel": "ECOM"
}
Security and Verification
To ensure the authenticity of webhook data, it is signed using HMAC-SHA256.
The signature is included in three HTTP headers within the webhook message.
Signature headers
| X-Paygate-Signature-Version | Version of the signature format (currently, v1) |
| X-Paygate-Timestamp | Unix epoch timestamp (seconds since 1970-01-01T00:00:00Z, UTC) |
| X-Paygate-Signature | Signature in the format |
Signature Generation (Axepta BNP-Paribas Online)
signed_payload = timestamp + "." + raw_json_body
signature = HMAC_SHA256(secret, signed_payload)
secret– HMAC key- The generated
Signatureis encoded 'hex' and the header is set as follows:
X-Paygate-Signature: v1=<hex-hmac>Signature Verification (Merchant)
To verify the authenticity of the webhook message data:
Extract the data carried by the HTTP headers:
X-Paygate-TimestampX-Paygate-Signature
Take the raw JSON payload data (the binary data received)
Calculate the HMAC with the extracted data
- signed_payload = timestamp + "." + raw_body expected_signature = HMAC_SHA256(secret, signed_payload)
- Compare the calculated signature with the received signature using a "constant-time" method.
- Validate the webhook if:
- The signatures are identical
- The Timestamp is within ±5 minutes of your local clock.
Integration Recommendations
- Always verify the transaction via the
getByPayIdendpoint, even if the client return suggests success. - Always process the webhook.
- Always verify the authenticity of the webhook data by validating its signature.
- Log all return/cancel/webhook calls.