Request Elements
In order to start a server-to-server card payment sequence please post the following key-value-pairs to
https://paymentpage.axepta.bnpparibas/direct.aspx |
Notice: For security reasons, Axepta Platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.
Notice: In case of a merchant initiated recurring transaction the JSON objects (besides credentialOnFile and card), the URLNotify and TermURL are not mandatory parameters, because no 3D Secure and no risk evaluation is done by the card issuing bank and the payment result is directly returned within the response.
Parameter | Format | CND | Description | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
ans..30 | M | MerchantID, assigned by ComputopAxepta. Additionally this parameter has to be passed in plain language too. | |||||||||
MsgVer | ans..5 | M | Message version. Values accepted:
| ||||||||
TransID | ans..64 | M | TransactionID provided by you which should be unique for each payment | ||||||||
RefNr | ans..30 | O | 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 BNP settlement file (CTSF) we cannot add the additional payment data. Notes:
| ||||||||
schemeReferenceID | ans..64 | C | Card scheme specific transaction ID required for subsequent credential-on-file payments, delayed authorizations and resubmssions. Mandatory: CredentialOnFile – initial false – unschedule MIT / recurring | industrySpecificTxType | ans..20 | C | This parameter is required whenever an industry specific transaction is processed according to the card brands MIT (Merchant Initiated Transactions) Framework. Values accepted: | ||||
Values | Comments | ||||||||||
Resubmission | A merchant performs a re-submission in cases where it requested an authorization, but received a decline due to insufficient funds; however, the goods or services were already delivered to the cardholder. Merchants in such scenarios can resubmit the request to recover outstanding debt from cardholders. | ||||||||||
Reauthorization | A merchant initiates a re-authorization when the completion or fulfillment of the original order or service extends beyond the authorization validity limit set by Visa. There are two common re-authorization scenarios: • Split or delayed shipments at eCommerce retailers. A split shipment occurs when not all the goods ordered are available for shipment at the time of purchase. If the fulfillment of the goods takes place after the authorization validity limit set by Visa, eCommerce merchants perform a separate authorization to ensure that consumer funds are available. • Extended stay hotels, car rentals, and cruise lines. A re-authorization is used for stays, voyages, and/or rentals that extend beyond the authorization validity period set by Visa. | DelayedCharges | Delayed charges are performed to process a supplemental account charge after original services have been rendered and respective payment has been processed.|||||||||
NoShow | Cardholders can use their Visa cards to make a guaranteed reservation with certain merchant segments. A guaranteed reservation ensures that the reservation will be honored and allows a merchant to perform a No Show transaction to charge the cardholder a penalty according to the merchant’s cancellation policy. Note: For merchants that accept token-based payment credentials to guarantee a reservation, it is necessary to perform a CIT (Account Verification Service) at the time of reservation to be able perform a No Show transaction later. | ||||||||||
Amount | n..10 | M | Amount in the smallest currency unit (e.g. EUR Cent). Please contact the Computop Helpdesk, if you want to capture amounts <100 (smallest currency unit). | ||||||||
Currency | a3 | M | Currency, three digits DIN / ISO 4217, e.g. EUR, USD, GBP. Please find an overview here: A1 Currency table EN | ||||||||
card | JSON | M | Card data | ||||||||
Capture | an..6 | OM | Determines the type and time of capture.
| ||||||||
channel | a..20 | C | Indicates the type of channel interface being used to initiate the transaction. Values accepted:
If not present the value | ||||||||
billingDescriptor | ans..22 | O | A descriptor to be printed on a cardholder’s statement. Please also refer to the additional comments made elswhere for more information about rules and regulations. | ||||||||
OrderDesc | ans..768 | O | Order description | ||||||||
TermURL | ans..256 | MO | In case of 3-D Secure 1.0 fallback: the URL the customer will be returned to at the end of the 3-D Secure 1.0 authentication process. | ||||||||
AccVerify | a3 | O | Indicator to request an account verification (aka zero value authorization). If an account verification is requested the submitted amount will be optional and ignored for the actual payment transaction (e.g. authorization). Values accepted:
| ||||||||
JSON | O | Object specifying authentication policies and excemption handling strategies | |||||||||
JSON | C | Object detailing authentication data in case authentication was performed through a third party or by the merchant | |||||||||
JSON | O | Prior Transaction Authentication Information contains optional information about a 3-D Secure cardholder authentication that occurred prior to the current transaction | JSON | M | Accurate browser information are needed to deliver an optimized user experience. Required for 3-D Secure 2.0 transactions. | ||||||
JSON | O | The account information contains optional information about the customer account with the merchant. Optional for 3-D Secure 2.0 transactions. | |||||||||
JSON | C | The customer that is getting billed for the goods and / or services. Required unless market or regional mandate restricts sending this information. | |||||||||
JSON | C | The customer that the goods and / or services are sent to. Required (if available and different from billToCustomer) unless market or regional mandate restricts sending this information. | |||||||||
JSON | C | Billing address. Required for 3-D Secure 2.0 (if available) unless market or regional mandate restricts sending this information. | |||||||||
JSON | C | Shipping address. If different from billingAddress, required for 3-D Secure 2.0 (if available) unless market or regional mandate restricts sending this information. | |||||||||
JSON | C | Object specifying type and series of transactions using payment account credentials (e.g. account number or payment token) that is stored by a merchant to process future purchases for a customer. Required if applicable. | |||||||||
JSON | O | The Merchant Risk Indicator contains optional information about the specific purchase by the customer | |||||||||
subMerchantPF | JSON | O | Object specifying SubMerchant (Payment Facilitator) details | ||||||||
an..256 | M | The merchant URL that receive asynchrounous reqeusts during the authentication process | |||||||||
UserData | ans..1024 | O | If specified at request, Paygate forwards the parameter with the payment result to the shop. | ||||||||
an64 | M | Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: |
General parameters for credit card payments via socket connection
Please note the additional parameter for a specific credit card integration in the section "Specific parameters"
Response Elements
The following table describes the result parameters with which the Axepta Platform responds to your system
pls. be prepared to receive additional parameters at any time and do not check the order of parameters
the key (e.g. MerchantId, RefNr) should not be checked case-sentive
Parameter | Format | CND | Description |
---|---|---|---|
ans..30 | M | MerchantID, assigned by Computop | |
PayID | an32 | M | ID assigned by Paygate for the payment, e.g. for referencing in batch files as well as for capture or credit request. |
XID | an32 | M | ID for all single transactions (authorisation, capture, credit note) for one payment assigned by Paygate |
TransID | ans..64 | M | TransactionID provided by you which should be unique for each payment |
a..20 | M | Status of the transaction. Values accepted:
| |
an12 | M | 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:
| |
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 | an8 | M | Error code according to Paygate Response Codes (A4 Error codes) |
UserData | ans..1024 | O | If specified at request, Paygate forwards the parameter with the payment result to the shop. |
JSON | M | The Card Range Data data element contains information that indicates the most recent EMV 3-D Secure version supported by the ACS that hosts that card range. It also may optionally contain the ACS URL for the 3-D Secure Method if supported by the ACS and the DS Start and End Protocol Versions which support the card range. | |
JSON | M | Object containing the data elements required to construct the Payer Authentication request in case of a fallback to 3-D Secure 1.0. | |
ans..64 | C | Card scheme specific transaction ID required for subsequent credential-on-file payments, delayed authorizations and resubmssions. | |
JSON | M | Card data | |
JSON | O | Object containing IP information | |
JSON | M | Authentication data | |
JSON | C | In case the authentication process included a cardholder challenge additional information about the challenge result will be provided. |