Wirecard
Follow the standard PaymentsOS integration procedure, and then apply the relevant extra specifications described below.
- API Version
- Payment Methods
- Currencies
- Features
- Requests
- Setup Procedures
- Integration Procedures
- Testing
API Version
Minimum required API version: 1.1.0
The following features require an API version higher than the minimum:
- 3DS 2.0 External requires API version 1.3.0
Payment Methods
| Payment Method | Payment Method Type |
|---|---|
| American Express | Cards |
| ArCa | Cards |
| Aura | Cards |
| CartaSi | Cards |
| Carte Bancaire | Cards |
| Carte Bleue | Cards |
| China Union Pay | Cards |
| Dankort | Cards |
| Hiper | Cards |
| Hipercard | Cards |
| JCB | Cards |
| MAESTRO | Cards |
| MASTERCARD | Cards |
| MIR | Cards |
| PostePay | Cards |
| RUPAY | Cards |
| UATP | Cards |
| UnionPay Online Payments | Cards |
| UPO | Cards |
| Uzcard | Cards |
| V PAY | Cards |
| VISA | Cards |
Currencies
Wirecard supports all currencies.
Features
The following table provides an overview of all supported and non-supported features.
| Feature | Supported |
|---|---|
 3DS 1.0 External | Yes |
| 3DS 1.0 Internal | No |
| 3DS 2.0 External | Yes |
| 3DS 2.0 Internal | No |
| Installments | No |
| Level 2 and 3 Data | No |
| Retrieve Supported Payment Methods | No |
| Statement Soft Descriptor | Yes |
| Stored Credentials Flag | Yes |
| Transaction Processing without CVV | Yes |
Requests
The following table lists all supported requests for card-based transactions. Use the bodybuilder to create a sample request body for each request type.
| Request | Partial/Multiple | Mode |
|---|---|---|
| Authorize | Partial and multiple are not supported | Synchronous |
| Capture | Both partial and multiple are supported | Synchronous |
| Charge | Not Applicable | Synchronous |
| Refund | Partial and multiple are not supported | Synchronous |
| Void | Not Applicable | Synchronous |
Setup Procedures
The following table lists the setup procedures that are specific to this provider.
Integration Procedures
The following section lists the integration procedures that are specific to this provider.
Passing a Consent Transaction ID
What you should already know
This section assumes you are familiar with the integration procedures for reusing a customer's card information and passing a Card on File (COF) indicator. If not, make sure to read Passing a Card on File Indicator before moving on to the explanations below.
When integrating with Wirecard, it is recommended to pass the value of the transaction_id as the ID that identifies the initial consent transaction. As the first step after initiating the consent transaction request, you must therefore parse the request response to determine that the request was handled by Wirecard. You can then pass the value of the value of the transaction_id (returned in the provider_data object of the request response data) in the subsequent authorization, charge or credit requests. Make sure to do so in the provider_specific_data.wirecard.additional_details.cof_consent_transaction_id field:
...
"provider_specific_data": {
"wirecard": {
"additional_details": {
"cof_consent_transaction_id": "3715246843"
}
}
},
...
Beware that the format of the transaction_id differs from the network_transaction_id (which you would use as the as the consent transaction ID when integrating with other providers). This implies that if the initial consent transaction was handled by Wirecard, you should not pass the transaction_id in the cof_transaction_indicators.cof_consent_transaction_id field as well, as this may impact your acceptance rates in the event that your subsequent transaction requests are routed to a provider other than Wirecard.
Note
Under the hood, Wirecard uses its own logic to map the the transaction_id to the format required by the card issuers.
Testing
For test credentials, see Test Access Data and Credentials in the Wirecard documentation.