Wirecard

Follow the standard PaymentsOS integration procedure, and then apply the relevant extra specifications described below.

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 MethodPayment Method TypeNotes
American ExpressCards3DS 2 external flows are not yet supported for American Express.
ArCaCards
AuraCards
CartaSiCards
Carte BancaireCards
Carte BleueCards
China Union PayCards
DankortCards
HiperCards
HipercardCards
JCBCards
MAESTROCards
MASTERCARDCards
MIRCards
PostePayCards
RUPAYCards
UATPCards
UnionPay Online PaymentsCards
UPOCards
UzcardCards
V PAYCards
VISACards

Currencies

Wirecard supports all currencies.

Features

The following table provides an overview of all supported and non-supported features.

FeatureSupported
3DS 1.0 ExternalYes
3DS 1.0 InternalNo
3DS 2.0 ExternalYes
3DS 2.0 InternalNo
InstallmentsNo
Level 2 and 3 DataNo
Retrieve Supported Payment MethodsNo
Statement Soft DescriptorYes
Stored Credentials FlagYes
Transaction Processing without CVVYes

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.

RequestPartial/MultipleMode
AuthorizePartial and multiple are not supportedSynchronous
Capture Both partial and multiple are supportedSynchronous
Charge Not ApplicableSynchronous
RefundPartial and multiple are not supportedSynchronous
Void Not ApplicableSynchronous

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.

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.

results matching ""

    No results matching ""