Contents
Card payments management
Capture
The merchant can choose one of these different options of capture:
- Manual capture
- Automatic capture
- Automatic capture with customized delay (number from 1 to 696)
When choosing the manual mode, it’s necessary for the merchant to validate manually each transaction. A transaction must be validated before 7 days. Captures are possible via a Server-to-Server connection. To perform captures via a Server-to-Server connection please use the following URL:
When choosing the automatic, capture is made every day at the end of the day.
When choosing the automatic mode with customized delay, the merchant sets a delay in hours (from 1 to 696) that corresponds to the frequency of capture
Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.
The following table describes the encrypted payment request parameters:
Parameter | Format | CND | Description |
|---|---|---|---|
| RefNr | an12 | OC | Merchant’s unique reference number, which serves as payout reference in the acquirer EPA file. Please note, without the own shop reference delivery you cannot read out the EPA transaction and regarding the additional settlement file we cannot add the additional payment data. Notes:
In cas of manual capture, the RefNr should be the same for authorization (payement creation) and capture. If values are different, the financial reconciliation will not work. |
MerchantID | ans..30 | M | Merchant ID, assigned by BNP |
PayID | an32 | M | ID assigned by the payment platform for the payment |
TransID | ans..64 | M | TransactionID which should be unique for each payment |
MAC | an64 | M | Hash Message Authentication Code (HMAC) with SHA-256 algorithm |
Amount | n..10 | M | Amount in the smallest currency unit (e.g. EUR Cent). Please contact the helpdesk, if you want to capture amounts < 100 (smallest currency unit). |
Currency | a3 | M | Currency, three digits DIN / ISO 4217 |
ReqID | ans..32 | O | To avoid double payments, enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction is submitted again with the same ReqID, the payment platform will not carry out the payment, but will just return the status of the original transaction. Please note that the payment platform must have a finalized transaction status for the first initial action. Submissions with identical ReqID for an open status will be processed regularly. |
| FinishAuth | a1 | C | Only with ETM: Transmit value <Y> in order to stop the renewal of guaranteed authorisations and rest amounts after partial captures. Please use this parameter only if you are using the additional function ETM (Extended Transactions Managament). |
Textfeld1 | ans..30 | O | Card holder information: Name |
Textfeld2 | ans..30 | O | Card holder information: City |
The following table describes the payment platform‘s response parameters:
| Parameter | Format | CND | Description | |||
|---|---|---|---|---|---|---|
| RefNr | an12 | OC | Merchant’s unique reference number, which serves as payout reference in the acquirer EPA file. Please note, without the own shop reference delivery you cannot read out the EPA transaction and regarding the additional settlement file we cannot add the additional payment data. Notes:
| |||
MID | ans..30 | M | MerchantID | |||
PayID | an32 | M | ID assigned by the payment platform for the payment, e.g. for referencing in batch files | |||
XID | an32 | M | ID for all single transactions (authorisation, capture, refund) for one payment assigned by the payment platform | |||
TransID | ans..64 | M | Merchant’s transaction number | |||
Status | a..50 | M | OK or FAILED | |||
Description | ans..1024 | M | Further details in the event that payment is rejected. Please do not use the Description but the Code parameter for the transaction status analysis! | |||
Code | n8 | M | Error code according to the payment platform Response Codes Excel file | |||
Partial captures are also possible by setting the « Amount » parameter with the partial amount to capture in the payment request, or via the back office by visualizing the transaction details then setting the partial amount to capture.
Cancellation
Cancellation function allows to cancel a transaction before it gets captured.
BNP Paribas manages the cancellation requests by proceeding to 2 verifications:
- The amount: It’s forbidden to cancel an amount that is superior to the initial amount of the transaction.
- Payment capture time: Once a payment is captured, it can’t be cancelled anymore.
To make a cancellation, use the following URL:
Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.
Notice: Reverse.aspx does not only reverse authorizations, but any last transaction stage. If the last transaction was a capture, Reverse.aspx initiates the reverse, e.g. a refund. Therefore, the utmost caution is urged. Use is at your own risk. We recommend checking the transaction status with Inquire.aspx before using Reverse.aspx.
(Further information about inquire.aspx you can find within the documentation Status requests.)
The following table describes the encrypted payment request parameters:
Parameter | Format | CND | Description |
|---|---|---|---|
MerchantID | ans..30 | M | MerchantID |
PayID | an32 | M | the payment platform ID for the identification of a payment |
TransID | ans..64 | M | TransactionID which should be unique for each payment |
Amount | n..10 | M | Amount in the smallest currency unit (e.g. EUR Cent). Please contact the helpdesk, if you want to capture amounts < 100 (smallest currency unit). The amount should be the same as the authorization. Partial reverse is not available |
Currency | a3 | M | Currency code, three digits DIN / ISO 4217 |
MAC | an64 | M | Hash Message Authentication Code (HMAC) with SHA-256 algorithm |
ReqID | ans..32 | O | To avoid double payments, enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction is submitted again with the same ReqID, the payment platform will not carry out the payment, but will just return the status of the original transaction. Please note that the payment platform must have a finalized transaction status for the first initial action. Submissions with identical ReqID for an open status will be processed regularly. |
The following table describes the payment platform response parameters:
| Paramater | Format | CND | Description | |||
|---|---|---|---|---|---|---|
MID | ans..30 | MC | MerchantID | |||
PayID | an32 | M | ID assigned by the payment platform for the payment, e.g. for referencing in batch files | |||
XID | an32 | M | ID for all single transactions (authorisation, capture, refund) for one payment assigned by the payment platform | |||
TransID | ans..64 | M | Merchant’s transaction number | |||
Status | a..50 | M | OK or FAILED | |||
Description | ans..1024 | M | Further details in the event that payment is rejected. Please do not use the Description but the Code parameter for the transaction status analysis! | |||
Code | n8 | M | Error code according to the payment platform Response Codes Excel file | |||
Refunds
Refunds allow to re-credit a customer who was previously debited (product not delivered, product damaged, product sent back…). The customer’s bank account is credited with the exact amount as the debit amount of the merchant. The merchant can refund a customer until 12 months following the purchase.
Refunds are not permitted for unpaid transactions.
Refunds are possible via a Server-to-Server connection. The payment platform permits refunds which relate to a capture previously activated by the payment platform and allows merchants to carry out refunds without a reference transaction. This section describes the processing of refunds with reference transactions. If you refer to a capture for a refund, the amount of the refund is limited to the amount of the previous capture.
To carry out a refund with a reference transaction, please use the following URL:
Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.
The following table describes the encrypted payment request parameters:
Parameter | Format | CND | Description |
|---|---|---|---|
| RefNr | an12 | OC | Merchant’s unique reference number, which serves as payout reference in the acquirer EPA file. Please note, without the own shop reference delivery you cannot read out the EPA transaction and regarding the additional settlement file we cannot add the additional payment data. Notes:
|
MerchantID | ans..30 | M | Merchant ID, assigned by BNP |
PayID | an32 | M | ID assigned by the payment platform for the payment |
TransID | ans..64 | M | TransactionID which should be unique for each payment |
MAC | an64 | M | Hash Message Authentication Code (HMAC) with SHA-256 algorithm |
Amount | n..10 | M | Amount in the smallest currency unit (e.g. EUR Cent). Please contact the helpdesk, if you want to capture amounts < 100 (smallest currency unit). |
Currency | a3 | M | Currency, three digits DIN / ISO 4217 |
OrderDesc | ans..768 | O | Merchant's reference number |
ReqID | ans..32 | O | To avoid double payments, enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction is submitted again with the same ReqID, the payment platform will not carry out the payment, but will just return the status of the original transaction. Please note that the payment platform must have a finalized transaction status for the first initial action. Submissions with identical ReqID for an open status will be processed regularly. |
Textfeld1 | ans..30 | O | Card holder information: Name |
Textfeld2 | ans..30 | O | Card holder information: City |
The following table describes the payment platform response parameters:
| Parameter | Format | CND | Description | |||
|---|---|---|---|---|---|---|
| RefNr | an12 | OC | Merchant’s unique reference number, which serves as payout reference in the acquirer EPA file. Please note, without the own shop reference delivery you cannot read out the EPA transaction and regarding the additional settlement file we cannot add the additional payment data. Notes:
| |||
MID | ans..30 | M | MerchantID | |||
PayID | an32 | M | ID assigned by the payment platform for the payment, e.g. for referencing in batch files | |||
XID | an32 | M | ID for all single transactions (authorization, capture, refund) for one payment assigned by the payment platform | |||
TransID | ans..64 | M | Merchant’s transaction number | |||
Status | a..50 | M | OK or FAILED | |||
Description | ans..1024 | M | Further details in the event that payment is rejected. Please do not use the Description but the Code parameter for the transaction status analysis! | |||
Code | n8 | M | Error code according to the payment platform Response Codes Excel file | |||