Credit CardREST APIPayment Mode, Countries and Currencies
Communication FormatsThis table illustrates how credit card notifications are encoded and which formats and methods can be used for requests and responses.
Test Credentials
Refer to one of the following tables to complete your test credentials: Non-3D (Manual Card Brand Recognition) Demo
Transaction TypesThis section describes Credit Card transaction types that can be used with the Wirecard Payment Gateway. For each transaction type we provide a Credit Card specific introduction. We explain the transaction type’s availability and restrictions. We look at the conditions or preconditions required to process this transaction type. You get the best knowledge of our transaction types when you send an XML request to our endpoint. We describe the content and structure of these requests in the section "Sending Data". For reference we also provide a response that can be expected. Where applicable we set up a flow of subsequent transaction types (e.g. authorization > capture-authorization). Refer to the complete field list for credit card transactions. In Update of Refund Transactions for Mastercard and Visa Advantages
We are updating refund transactions for credit card (Mastercard and Visa). With the update, the response to a refund-request returns the
List of Transaction Types
void vs. refund It is often the case that the merchants must withdraw an online shopping process. When the consumer wants to buy a product or service online, Wirecard Payment Gateway (WPG) initiates a payment process. When the merchants withdraw this process, they can stop the process in two ways. Either with a void or a refund. A void is only possible as long as no money transfer has been initiated. As soon as WPG has initiated the payment flow to the acquirer the merchants must return the funds to the consumer via a refund process. Workflow Voiding a transaction requires a reference to the transaction that shall be voided. The void transaction contains a Here is an example how to void a capture.  refund Workflow Refunding a transaction requires a reference to the transaction that shall be refunded. The refund transaction contains a Here is an example how to refund a capture. OCT Eligibility Check Wirecard Payment Gateway uses the transaction type authorization-only, to find out whether the card in use is eligible for original credit transactions (OCT). If you want to use this eligibility check contact merchant support for details. authorization authorization checks the consumer’s account for credibility and reserves a fixed amount of funds. Reservation means that Wirecard Payment Gateway informs the card holder’s issuer about the upcoming transaction. The reservation lasts from three to thirty days, depending on the acquirer and card brand. Within that time the merchants can prepare the selected products or services for shipping. Once the merchants initiate the shipping, they also initiate a capture-authorization which will transfer the authorized amount from the issuer to the acquirer.
Real-Life Example Consumers order a dishwasher for 500 EUR online. authorization checks the consumers' account immediately and reserves 500 EUR. When the merchants start the shipping process, a capture-authorization will transfer the 500 EUR from the consumers' to the merchants' account. Availability and Restrictions authorization is generally available. Every authorization request has a time limit depending on the card schemes. The limit refers to the period of time from sending an authorization to sending a capture-authorization. Typically, the limit ranges from three to thirty days, depending on the acquirer and card brand. It is recommended to check the card schemes for details. An authorization may be denied. Some reasons (among others) for the denial are:
Sending Data We only list samples for requests and responses. Notifications follow the general structure described in General Platform Features. Are you using Postman to send the requests?
Status Codes In authorization Using Card Data Request If the credit card is used for the first time, the authorization request will contain the clear card data. The first response immediately replaces the explicit card data with a token. The token will be used from then on. Handling clear card data requires a strong degree of PCI DSS compliance. If your PCI DSS compliance is not sufficient, you can use our Wirecard Payment Page v2. Request Header XML authorization Request (Successful) Response
XML authorization Response (Successful) authorization Using a Token Request If the credit card is already known to the merchant, the authorization request will not contain the clear card data. It will contain the token data instead. Request Header XML authorization Request (Successful) Response XML authorization Response (Successful) A successful authorization response can be followed by a void-authorization (details see void). void-authorization Request Request Header XML void-authorization Request (Successful) Response XML void-authorization Response (Successful) capture-authorization Introduction A capture-authorization transfers an authorized amount from the consumer bank account to the acquirer (merchant’s bank account). Availability and Restrictions A capture-authorization must be initiated in a defined period of time after a successful authorization (details see authorization).
Sequence A capture-authorization follows an authorization. Sending Data We only list samples for requests and responses. Notifications follow the general structure described in General Platform Features. Are you using Postman to send the requests?
Status Codes In Fields Sample Request Header XML authorization Request (Successful) Response Fields Sample XML authorization Response (Successful) A successful authorization may be followed by a
capture-authorization Request Fields Sample Request Header XML capture-authorization Request (Successful) Response Fields Sample XML capture-authorization Response (Successful) A successful capture-authorization may be followed by a
Request Fields Sample Request Header XML void-capture Request (Successful) Response Fields Sample XML void-capture Response (Successful) Request Fields Sample Request Header XML refund-capture Request (Successful) Response Fields Sample XML refund-capture Response (Successful) purchase Introduction purchase transfers the transaction amount without preceding reservation from the consumer directly to the merchant. With this transaction type merchants collect the money immediately while selling goods or providing a service to the consumers. Merchants use purchase in most of the cases to process POS transactions. It is also used for immediate online payments, such as software downloads. Merchants can also perform recurring payments using the transaction type purchase. The first payment of a recurring payment process starts with the transaction type purchase which is followed by referenced-purchase transactions. Real-Life Example Single Payment For POS payments, purchase is used when consumers hire a taxi and pay the taxi fare with their credit card. Or the consumers shop in a department store or grocery store and pay at the check out using their credit card. In an online shopping process, purchase is used when consumers download software, a movie or audio files. Recurring Payment When consumers subscribe to a magazine or pay an insurance, they face periodically repeating payments for a certain period of time. When consumers want to pay online, merchants can arrange this type of payment with the transaction type referenced-purchase referencing a purchase transaction. Availability and Restrictions No restrictions apply to this transaction type. A purchase is generally available. A void-purchase can stop a successfully completed purchase (merchant received a success purchase notification) as long as the funds transfer has not been initiated. The same logic applies to void a refund-purchase. That means, a void-refund-purchase can stop a refund-purchase. If merchants want to cancel the purchase after the funds transfer was initiated, they must do it with a refund-purchase. A referenced-purchase is only possible, if there is a preceding successful purchase transaction to refer to, which contains a Sequence A purchase can be a stand-alone transaction. It may be followed by a void-purchase, a referenced-purchase or a refund-purchase. A refund-purchase may be followed by a void-refund-purchase. Sending Data We only list samples for requests and responses. Notifications follow the general structure described in General Platform Features. Are you using Postman to send the requests?
Status Codes In purchase Using Card Data Request If the credit card is used for the first time, the purchase request will contain the explicit card data. The first response immediately replaces the explicit card data with a token. The token will be used from then on. Handling explicit card data requires a strong degree of PCI DSS compliance. If your PCI DSS compliance is not sufficient, you can use our Wirecard Payment Page v2. Fields Sample Request Header XML purchase Request (Successful) Response Fields
Sample XML purchase Response (Successful) purchase Using a Token Request If the credit card is already known to the merchant, a token already exists and can be used from the beginning. Fields Sample Request Header XML purchase with token Request (Successful) Response Fields Sample XML purchase with token Response (Successful) A successful purchase response can be followed by
The following sample set describes a flow of
recurring purchase transactions which are connected via The Initial Transaction The Recurring Transactions The Final Transaction The Workflow purchase Request (recurring/first) Fields Sample Request Header XML (recurring/first) purchase Request (Success) purchase Response (recurring/first) Fields Sample XML (recurring/first) purchase Response (Success) referenced-purchase Request (recurring/recurring) Fields Sample Request Header XML referenced-purchase Request (Success) referenced-purchase Response (recurring/recurring) Fields Sample XML referenced-purchase Response (Success) referenced-purchase Request (recurring/final) Fields Sample Request Header XML referenced-purchase Request (Success) referenced-purchase Response (recurring/final) Fields Sample XML referenced-purchase Response (Success)
We only list field descriptions for requests and responses. Notifications follow the general structure described in General Platform Features. Request Fields Sample Request Header XML void-purchase Request (Successful) Response Fields Sample XML void-purchase Response (Successful) refund-purchase Merchants use a refund-purchase to refund a purchase or parts of it after the funds transfer was initiated. We only list field descriptions for requests and responses. Notifications follow the general structure described in General Platform Features. Request Fields Sample Request Header XML refund-purchase Request (Successful) Response Fields Sample XML refund-purchase Response (Successful) A successful refund-purchase response can be followed by a void-refund-purchase (details see void). void-refund-purchase With this transaction type you can void a successful refund-purchase until the funds transfer has been triggered. Request Fields Sample Request Header XML void-refund-purchase Request (Successful) Response Fields Sample XML void-refund-purchase Response (Successful) FieldsThis is the general field reference for credit card transactions.
We provide the request and the response fields in two separate sections:
The fields are ordered hierarchically and in separate tables. Some fields listed in this table are complex type fields, e.g.
For example, Field Definitions Each field table contains the following columns:
XML Elements Click the X in the respective column for request and response fields. Please refer to our XSD for the structural relationship between these fields.
Request
It is used for card present transactions. You can find additional
Consumer’s Personal Identification Number data are always encrypted. A card present payment process can be initiated by a POS terminal (PIN pad) transaction processed online (and/or offline). The terminal accepts, encrypts and forwards the cardholder’s PIN.
With this element you can send money to the consumer. This can be the case, if you are
For card present transactions.
Response
Here you can find the
The Address Verification System (AVS) is an advanced credit card security service that is integrated in the Wirecard credit card processing network to help thwart identity theft. When a user makes an online purchase with a credit card, their billing address is required. The house number and postal code of the billing address is compared to the billing address held on file by the card issuing bank. If the address does not match, the transaction can be declined. AVS is an on-demand service which is configured by Wirecard.
Wirecard can configure
It is used for card present transactions. Here we show the response fields of
Payment FeaturesTokenization Introduction Tokenization defines a process through which sensitive data, such as credit card number, is replaced with a surrogate value known as a "token". This token serves as a reference or surrogate value for the original credit card data. Tokenization enables the merchant to use credit card data based on PCI DSS regulations, during a payment process. It is a service provided by Wirecard for its customers. The token, generated by Wirecard, reduces the merchant’s PCI DSS Scope. That means, merchants do not have to store sensitive primary account numbers. There are two options of using tokenization:
What is the difference between these two options?
The token-id The merchant sends an initial request to Wirecard Payment Gateway. This could be an authorization, for example. This request
contains all data concerning the goods, shipping etc, as well as the consumer’s credit card data. After the request of an authorization transaction was processed successfully, the response will not contain the information of the Credit Card <data> tag. The <data> tag will be replaced with a token-id in the <card-token> tag. As soon as the token-id is created, the token-id represents this special credit card. With that
token-id any recurring or other follow up transaction for this special credit card can be processed. As there is no additional encryption required, the use of the token-id reduces interaction and accelerates the credit card payment process. Especially from PCI DSS perspective, it is less critical. e.g. A capture-authorization as follow up transaction in the workflow does not need the <data> tag of the Credit Card but only the token-id. When using credit card, Wirecard Payment Gateway offers two different options to reference transactions. It depends on the merchant’s individual business needs and business processes, which type of referencing should be used. Look at the following table to understand the pros and cons of referencing with a token or with the parent-transaction-id.
If the merchant only hands through a payment process (using a token) and does not store card holder data, it reduces the merchant’s applicable controls required for PCI DSS validation. If the merchant wants to store card holder data (using The following table describes, which data can be stored and which data must not be stored to be PCI DSS compliant.
Referencing by token-id Referencing based on a token can be performed by using the Field With that feature it is possible to refer a NEW transaction to an already submitted initial transaction. In the initial transaction the cluster of the
Tokenize a Credit Card The transaction type tokenize converts credit card information into a token that can be used in subsequent payment transactions, instead of the actual credit card information. Workflow Fields The following fields must be sent either in the request or the response (M = Mandatory, O = Optional). For details of the affected fields see the field table.
Samples Detokenize a Credit Card The transaction type detokenize is the inverse of the transaction type tokenize. With the transaction type detokenize a token-id is provided to retrieve the original credit card information. Fields The following fields must be sent either in the request or the response (M = Mandatory, O = Optional). For details of the affected fields see the field table.
Samples
Dynamic Descriptor With the Dynamic Descriptor, merchants can itemize sales more clearly to the benefit of their customers, back office and consumer care management. As merchants can add sales-specific information to electronic settlement requests, consumers have a better understanding of what they purchased. This increases their level of satisfaction and reduces the number of chargebacks. Known as a dynamic descriptor, the details can be included in any settlement transaction, be it e-commerce, POS or MOTO. Data and Structure Merchant Name and Merchant Location are usually displayed on the cardholder’s bank statement. These fields or parts of them are used for presenting the dynamic data on the cardholder’s statement. Apart from such static data, the merchant can add transaction information to better reference their sales. For example, the merchant may use invoice number, booking ID or transaction ID. This data is typically passed along to the merchant. As this field has a fixed length, the longer the merchant name is, the smaller the number of digits allocated to dynamic information will be. Digits Allocation
Please be aware that industry-specific restrictions apply by card schemes. Please also note that it is up to the issuer to decide which data provided in the dynamic descriptor is printed on the cardholder’s statement. Wirecard can thus not guarantee that the dynamic descriptor data submitted to the issuers via the scheme networks is fully printed on the cardholder’s statement. Wirecard Bank (WDB) receives the transaction data from the Wirecard Payment Gateway, looks up the merchant address, consolidates static address details and dynamic sales data (including Merchant Name and Merchant Location) and routes the information along with the settlement request to the issuer. To what level the routed details will later appear on the customer’s card statement may vary from issuer to issuer. How It Works When a merchant sends a transaction request with a dynamic descriptor, the data provided in the reserved transaction field tag expands the address information registered in the card acquirer’s MID database.
Workflow
Payment Facilitator The Payment Facilitator model allows a Payment Service Provider with a Payment Facilitator license to aggregate credit card payments, collect funds resulting from credit card traffic and settle sub merchants directly. Requests
in Payment Facilitator traffic require additional sub merchant information in the The sub merchant information is mandatory for MasterCard, Visa, UPI and JCB traffic.
Recurring Transaction To submit a
recurring transaction the merchant must submit a request with the transaction type Credit Card specific Periodic Types Aside from the standard Periodic Types, Credit Card can also be used with the Periodic Types ucof The Unscheduled Credential on File (ucof) allows the merchant to reference a regularly based transaction (like an unlimited periodic payment or an installment payment) to an already successfully submitted transaction. ci The periodic type Possible Scenarios Shopping Online/Via an App Establish Stored Credential/First Transaction
Example: Establishment of Stored Credential/First Transaction Subsequent Cardholder Initiated Purchase
Example: Subsequent Cardholder initiated purchase Guest Account/Single Transaction
Example: Guest account/single transaction Recurring (R) or Installment (I) Transaction First Recurring or Installment
Example: First Recurring or Installment Subsequent Recurring or Installment Merchant Initiated Transaction
Example: Merchant initiated transaction ucof Example: auto-top up for transit or mobile - date is irregular, i.e. not known as usage driven
Example: First UCOF (sequence-type = 'first') Merchant Initiated Transaction
Example: Subsequent UCOF (sequence-type = 'recurring') Non-Referenced Capture In an offline transaction process it is possible to have a non-referenced capture authorization. The Wirecard Payment Gateway can support such a type of transaction when using a special A transaction is considered non-referenced capture when it meets all the following four conditions in the payment XML request:
If all conditions are met, then the transaction is sent to Wirecard Payment Gateway. The most
exceptional fact in this process is, that it is missing the Parent-Transaction-ID. By default Even though no parent transaction is available, captures which have not been referenced by Wirecard Payment Gateway can be processed. Cases like this will be handled a non-referenced Account Updater Account Updater is a feature facilitating recurring credit card payments. It informs the merchant about changes of cardholders' credit card details. It saves the cardholders the hassle of manually updating credit card details for each individual subscription. All types of recurring credit card payments can continue seamlessly even if
Furthermore, Account Updater informs the merchant when
Supported credit card brands:
Account Updater also covers brand flips between these two. What is updated by Account Updater? Recurring payments need a To activate and configure Account Updater, contact merchant support. Workflow Updating account information requires action on the merchant side (step 1 and step 6):
Files Both the request file and the
response file are plain text files without extension. The fields within the files are seperated by Request File The request file contains original e.g. AU.REQ.ID000000317588D017.D191015.S001 Request File Syntax: Header line syntax (line 1):
Detail lines syntax (records):
Sample Request File (Success): Sample Request File (Error): Response File The response file has the same name as the corresponding request file, only with "REQ" replaced by "RES": AU.RES.ID<MAID>.D<YYMMDD>.S<3-digit seq #> It contains
Response File Syntax: Header line syntax (line 1):
Detail lines syntax (records):
The footer has the same syntax as in the request file. Sample Response File (Success): Sample Response File (Error): Error Handling
Loyalty Programs Visa and Mastercard provide these loyalty programs for your consumers:
These programs allow you to enroll your consumers' cards and let them earn loyalty points based on the payments made with their cards. Both platforms have additional functionalities for you to connect to, such as loyalty calculation and redemption. Transaction Types Enroll a card in the corresponding loyalty program with the transaction type enrollment.
Test Credentials VOP
Workflow Enroll Card Transaction type must be
Add Card (VOP only) With VOP you can add additional cards to the same consumer’s account. Card type must be
Request Fields Most of the request fields used for the loyalty programs are the same as the Credit Card request fields. payment.
Response Fields Most of the response fields used for the loyalty programs are the same as the
Credit Card response fields.
Samples
VOP Enroll Card Request VOP Enroll Card Response VOP Add Card Request VOP Add Card Response VOP Tokenize Card Request VOP Tokenize Card Response VOP Enroll Tokenized Card Request
VOP Enroll Tokenized Card Response VOP Add Tokenized Card Request VOP Add Tokenized Card Response MCLS Enroll Card Request
MCLS Enroll Card Response MCLS Tokenize Card Request MCLS Tokenize Card Response MCLS Enroll Tokenized Card Request
MCLS Enroll Tokenized Card Response SamplesOn this page you can find all the XML and NVP samples available for Credit Card payment. Running the Test Samples Postman is a handy tool to send a request to our endpoints. We optimized our samples assuming you are using Postman.
The correct headers are generated automatically and appended to the request once you click Send. Figure 9. Postman Body section If you do not use Postman, use the test credentials as provided in the corresponding transaction type sample and make sure you replace Preauthorization XML XML Preauthorization Request (Successful) XML Preauthorization Response (Successful) XML Preauthorization Notification (Successful) XML Preauthorization Request (Failure) XML Preauthorization Response (Failure) XML Preauthorization Notification (Failure) NVP NVP Preauthorization Request (Successful) NVP Preauthorization Response (Successful) NVP Preauthorization Request (Failure) NVP Preauthorization Response (Failure) Authorization NVP NVP Authorization Request (Successful) NVP Authorization Response (Successful) NVP Authorization Request (Failure) NVP Authorization Response (Failure) Tokenization XML XML Tokenize Request (Successful) XML Tokenize Response (Successful) XML Tokenize Notification (Successful) XML Tokenize Request (Failure) XML Tokenize Response (Failure) XML Tokenize Notification (Failure) NVP NVP Tokenize Request (Successful) NVP Tokenize Response (Successful) NVP Tokenize Request (Failure) NVP Tokenize Response (Failure) Detokenization XML XML Detokenize Request (Successful) XML Detokenize Response (Successful) XML Detokenize Notification (Successful) XML Detokenize Request (Failure) XML Detokenize Response (Failure) XML Detokenize Notification (Failure) NVP NVP Detokenize Request (Successful) NVP Detokenize Response (Successful) NVP Detokenize Request (Failure) NVP Detokenize Response (Failure) Authorization Only XML XML Authorization Only Request (Successful) XML Authorization Only Response (Successful) XML Authorization Only Notification (Successful) XML Authorization Only Request (Failure) XML Authorization Only Response (Failure) XML Authorization Only Notification (Failure) NVP NVP Authorization Only Request (Successful) NVP Authorization Only Response (Successful) NVP Authorization Only Request (Failure) NVP Authorization Only Response (Failure) Authorization Supplementary This transaction type is not included in default configuration. XML XML Authorization Supplementary Request (Successful) XML Authorization Supplementary Response (Successful) XML Authorization Supplementary Notification (Successful) XML Authorization Supplementary Request (Failure) XML Authorization Supplementary Response (Failure) XML Authorization Supplementary Notification (Failure) NVP NVP Authorization Supplementary Request (Successful) NVP Authorization Supplementary Response (Successful) NVP Authorization Supplementary Request (Failure) NVP Authorization Supplementary Response (Failure) Capture Authorization NVP NVP Capture Authorization Request (Successful) NVP Capture Authorization Response (Successful) NVP Capture Authorization Request (Failure) NVP Capture Authorization Response (Failure) Referenced Authorization XML XML Referenced-Authorization Request (Successful) XML Referenced-Authorization Response (Successful) XML Referenced-Authorization Notification (Successful) XML Referenced-Authorization Request (Failure) XML Referenced-Authorization Response (Failure) XML Referenced-Authorization Notification (Failure) NVP NVP Referenced-Authorization Request (Successful) NVP Referenced-Authorization Response (Successful) NVP Referenced-Authorization Request (Failure) NVP Referenced-Authorization Response (Failure) Referenced Purchase NVP NVP Referenced-Purchase Request (Successful) NVP Referenced-Purchase Response (Successful) NVP Referenced-Purchase Request (Failure) NVP Referenced-Purchase Response (Failure) Purchase NVP NVP Purchase Request (Successful) NVP Purchase Response (Successful) NVP Purchase Request (Failure) NVP Purchase Notification (Failure) Credit XML XML Credit Request (Successful) XML Credit Response (Successful) XML Credit Notification (Successful) XML Credit Request (Failure) XML Credit Response (Failure) XML Credit Notification (Failure) NVP NVP Credit Request (Successful) NVP Credit Response (Successful) NVP Credit Request (Failure) NVP Credit Response (Failure) Original Credit XML XML Original Credit Request (Successful) XML Original Credit Response (Successful) XML Original Credit Notification (Successful) XML Original Credit Request (Failure) XML Original Credit Response (Failure) XML Original Credit Notification (Failure) NVP NVP Original Credit Request (Successful) NVP Original Credit Response (Successful) NVP Original Credit Request (Failure) NVP Original Credit Response (Failure) Refund Capture NVP NVP Refund Capture Request (Successful) NVP Refund Capture Response (Successful) NVP Refund Capture Request (Failure) NVP Refund Capture Response (Failure) Refund Purchase NVP NVP Refund Purchase Request (Successful) NVP Refund Purchase Response (Successful) NVP Refund Purchase Request (Failure) NVP Refund Purchase Response (Failure) Void Authorization NVP NVP Void Authorization Request (Successful) NVP Void Authorization Response (Successful) NVP Void Authorization Request (Failure) NVP Void Authorization Response (Failure) Void Authorization Supplementary XML XML Void Authorization Supplementary Request (Successful) XML Void Authorization Supplementary Response (Successful) XML Void Authorization Supplementary Notification (Successful) XML Void Authorization Supplementary Request (Failure) XML Void Authorization Supplementary Response (Failure) XML Void Authorization Supplementary Notification (Failure) NVP NVP Void Authorization Supplementary Request (Successful) NVP Void Authorization Supplementary Response (Successful) NVP Void Authorization Supplementary Request (Failure) NVP Void Authorization Supplementary Response (Failure) Void Capture NVP NVP Void Capture Request (Successful) NVP Void Capture Response (Successful) NVP Void Capture Request (Failure) NVP Void Capture Response (Failure) Void Credit XML XML Void Credit Request (Successful) XML Void Credit Response (Successful) XML Void Credit Notification (Successful) XML Void Credit Request (Failure) XML Void Credit Response (Failure) XML Void Credit Notification (Failure) NVP NVP Void Credit Request (Successful) NVP Void Credit Response (Successful) NVP Void Credit Request (Failure) NVP Void Credit Response (Failure) Void Original Credit XML XML Void Original Credit Request (Successful) XML Void Original Credit Response (Successful) XML Void Original Credit Notification (Successful) XML Void Original Credit Request (Failure) XML Void Original Credit Response (Failure) XML Void Original Credit Notification (Failure) NVP NVP Void Original Credit Request (Successful) NVP Void Original Credit Response (Successful) NVP Void Original Credit Request (Failure) NVP Void Original Credit Response (Failure) Void Preauthorization XML XML Void Preauthorization Request (Successful) XML Void Preauthorization Response (Successful) XML Void Preauthorization Notification (Successful) XML Void Preauthorization Request (Failure) XML Void Preauthorization Response (Failure) XML Void Preauthorization Notification (Failure) NVP NVP Void Preauthorization Request (Successful) NVP Void Preauthorization Response (Successful) NVP Void Preauthorization Request (Failure) NVP Void Preauthorization Response (Failure) Void Purchase NVP NVP Void Purchase Request (Successful) NVP Void Purchase Response (Successful) NVP Void Purchase Request (Failure) NVP Void Purchase Response (Failure) Void Refund Capture XML XML Void Refund Capture Request (Successful) XML Void Refund Capture Response (Successful) XML Void Refund Capture Notification (Successful) XML Void Refund Capture Request (Failure) XML Void Refund Capture Response (Failure) XML Void Refund Capture Notification (Failure) NVP NVP Void Refund Capture Request (Successful) NVP Void Refund Capture Response (Successful) NVP Void Refund Capture Request (Failure) NVP Void Refund Capture Response (Failure) Void Refund Purchase NVP NVP Void Refund Purchase Request (Successful) NVP Void Refund Purchase Response (Successful) NVP Void Refund Purchase Request (Failure) NVP Void Refund Purchase Response (Failure) Check Risk XML XML Check Risk Request (Successful) XML Check Risk Response (Successful) XML Check Risk Notification (Successful) XML Check Risk Request (Failure)
XML Check Risk Response (Failure) XML Check Risk Notification (Failure) NVP NVP Check Risk Request (Successful) NVP Check Risk Response (Successful) NVP Check Risk Request (Failure) NVP Check Risk Response (Failure) Check Enrollment XML Check Enrollment Request (Successful) XML Check Enrollment Response (Successful) Check Enrollment for 3D Secure 2 One-Time Payment Transactions XML Check Enrollment Request (Successful) XML Check Enrollment Response (Successful) Payment Facilitator Transactions XML XML Check Enrollment Request (Successful) XML Check Enrollment Response (Successful) XML Authorization Request (Successful) XML Authorization Response (Successful) XML Purchase Request (Successful) XML Purchase Response (Successful) NVP NVP Authorization Request (Successful) NVP Authorization Response (Successful) Check Payer Response XML Check Payer Response Request (Successful) XML Check Payer Response Response (Successful) Payment Request with PARes XML Purchase (Payment Request with PARes) Request (Successful) XML Purchase (Payment Request with PARes) Response (Successful) Payment Request with 3rd Party MPI XML Purchase (Payment Request with 3rd Party MPI) Request Card Types
Test CardsIn this section we provide test cards for a variety of card brands. These test cards allow you to trigger a certain behaviour when you send them to our endpoint. We provide test cards for 3D Secure, 3D Secure 2, and Non-3D Secure transactions. Example If you want to provoke the error status code 3D Secure Transactions When you do a 3D Secure transaction, WPG checks with the first request, whether the card is enrolled in 3D Secure. A transaction is 3D Secure, if the response returns a positive enrollment check and a positive authentication result. Enrollment and Authentication Values
Card Numbers for Successful Transactions With these card numbers you can provoke a successful response containing the status code
Card Numbers for Error Results With these card numbers you can provoke an error response containing a variety of status codes. American Express Use Card Type
Diners Use Card Type
Maestro Use Card Type
Mastercard Use Card Type
3D Secure 2 Transactions Table Key The 3D Secure 2 test card tables deviate in a few instances from the 3D Secure 1 tables.
3D Secure 2 Transactions Resulting in an Error With the following card numbers you can provoke error responses. 3D Secure 2 Transactions without Challenge
Non-3D Secure Transactions This section provides card numbers and CVCs which you can use to provoke certain Non-3D responses. To obtain the required response, send a purchase request to our endpoint using the corresponding card details provided here. For example: If you want to provoke the message "The card type is not processed by the authorization center. Please contact technical support." (Status Code = Status Code 201.0000 The resource was successfully created.
American Express Use Card Type
Diners Use Card Type
Maestro Use Card Type
Mastercard Use Card Type
Wirecard Payment Page v2Wirecard Payment Page v1 General InformationThis is a reference page for Credit Card. Here you find all the information necessary for integrating this payment method in your Hosted and Embedded Payment Page.
Below, you find example requests for all available transaction types, including field lists with short descriptions. These requests are designed for the testing environment and do not use real information.
All given requests return successful responses. For response verification examples, see the WPP v2 Security section. Test Credentials
purchaseA purchase transaction charges the account holder’s card and immediately transfers the reserved amount. For a successful transaction:
We provide ready-made JSON examples for each step of this process. You can find them below. Endpoint for Credit Card transactions. Initial Request The initial request creates the payment session. If it’s successful, you receive a URL as a response which redirects to the payment form. Request Headers
For a full structure of a request (optional fields included), see the JSON/NVP Field Reference section. 1. Create a Payment Session (Initial Request)
2. Redirect the Consumer to the Payment Page (Initial Response URL)
At this point, you need to redirect your consumer to Consumers are redirected to the payment form. There they enter their data and submit the form to confirm the payment. A payment can be:
The transaction result is the value of In any case (unless the consumer cancels the transaction on a 3rd party provider page), a base64 encoded response containing payment information is sent to the configured redirection URL. See Configuring Redirects and IPNs for WPP v2 for more details on redirection targets after payment & transaction status notifications. You can find a decoded payment response example below. 3. Parse and Process the Payment Response (Decoded Payment Response)
authorizationAn authorization transaction places the account holder’s funds on hold, pending future capture, re-authorization or void transaction. As with other referenceable transaction types, you can use WPP v2 only to create the authorization itself. To capture or register additional transactions referencing it, you need to use our REST API. For a successful transaction:
We provide ready-made JSON examples for each step of this process. You can find them below. Endpoint for Credit Card transactions. Initial Request The initial request creates the payment session. If it is successful, you receive a URL as a response which redirects to the payment form. Request Headers
For a full structure of a request (optional fields included), see the JSON/NVP Field Reference section. 1. Create a Payment Session (Initial Request)
2. Redirect the Consumer to the Payment Page (Initial Response URL)
At this point, you need to redirect your consumer to Consumers are redirected to the payment form. There they enter their data and submit the form to confirm the payment. A payment can be:
The transaction result is the value of In any case (unless the consumer cancels the transaction on a 3rd party provider page), a base64 encoded response containing payment information is sent to the configured redirection URL. See Configuring Redirects and IPNs for WPP v2 for more details on redirection targets after payment & transaction status notifications. You can find a decoded payment response example below. authorization (Response)
authorization-onlyAn authorization-only transaction verifies the validity of account holder’s card, but does not leave an authorized amount. authorization-only transactions require a zero requested amount. As with other referenceable transaction types, you can use WPP v2 only to create the authorization itself. To capture or register additional transactions referencing it, you need to use our REST API. For a successful transaction:
We provide ready-made JSON examples for each step of this process. You can find them below. Endpoint for Credit Card transactions. Initial Request The initial request creates the payment session. If it’s successful, you receive a URL as a response which redirects to the payment form. Request Headers
For a full structure of a request (optional fields included), see the JSON/NVP Field Reference section. 1. Create a Payment Session (Initial Request)
2. Redirect the Consumer to the Payment Page (Initial Response URL)
At this point, you need to redirect your consumer to Consumers are redirected to the payment form. There they enter their data and submit the form to confirm the payment. A payment can be:
The transaction result is the value of In any case (unless the consumer cancels the transaction on a 3rd party provider page), a base64 encoded response containing payment information is sent to the configured redirection URL. See Configuring Redirects and IPNs for WPP v2 for more details on redirection targets after payment & transaction status notifications. You can find a decoded payment response example below. 3. Parse and Process the Payment Response (Decoded Payment Response)
Post-Processing OperationsWPP v2 is best used to deal with "one-off" payments (e.g. regular, independent debit transactions) or the initial transaction in a chain of them (e.g. a first authorization in a chain of recurring transactions). However, when it comes to referencing a transaction for any kind of post processing operations - like a refund of one of your debit transactions - use our REST API directly. Check the REST API Credit Card specification for details on Credit Card specific post processing operations. There are multiple post processing operations available for Credit Card:
JSON/NVP Field ReferenceHere you can
JSON Structure for Credit Card Requests
Response-only Fields
Credit Card with 3D SecureTo process 3D Secure transactions, you need to have them enabled on your merchant account. Contact merchant support if 3D Secure was not enabled for you during Merchant setup.
To process a card payment with 3D Secure enabled: Add the
We provide ready-made JSON examples for each step of this process. You can find them below. Initial Request The initial request creates the payment session. If it’s successful, you receive a URL as a response which redirects to the payment form. Test Credentials
For a full structure of a request (optional fields included), see the JSON/NVP Field Reference section. 1. Create a Payment Session (Initial Request)
2. Redirect the Consumer to the Payment Page (Initial Response URL)
At this point, you need to redirect your consumer to Consumers are redirected to the payment form. There they enter their data and submit the form to confirm the payment. A payment can be:
The transaction result is the value of In any case (unless the consumer cancels the transaction on a 3rd party provider page), a base64 encoded response containing payment information is sent to the configured redirection URL. See Configuring Redirects and IPNs for WPP v2 for more details on redirection targets after payment & transaction status notifications. You can find a decoded payment response example below. 3. Parse and Process the Payment Response (Decoded Payment Response) Possible results for ECI field These are the possible scenarios for the value of the field 3D authentication successful The card issuing bank is 3D ready and cardholder is enrolled. (ECI Value: 05 - VISA/JCB/American Express; 02 - Mastercard) 3D authentication unsuccessfulEither the card issuing bank is not 3D ready or the cardholder is not enrolled. (ECI Value: 06 - VISA/JCB/American Express; 01 - Mastercard) 3D authentication unsuccessful or not attemptedEither a non-3D card or the card issuing bank does not handle the transaction as 3D Secure. (ECI Value: 07 - VISA/JCB/American Express; 00 - Mastercard)
3D Secure 2 - Additional FieldsTo create a payment session with Credit Card using 3D Secure 2 authentication, you need to include additional 3D Secure 2 fields in your initial request.
3DS2 Sample Request Additional Fields for 3DS2 A field can be Mandatory or Optional.
Installment Payment Plan (IPP) for WPP v2Installment Payment Plan is a feature that allows the consumer to pay in installments. Set up a contract with your issuing bank to agree on the IPP parameters. The issuing bank then provides Wirecard with these IPP parameters. IPP Characteristics
Installment Payment Plan works with transaction type purchase. IPP for Hosted Payment Page
Workflow
IPP for Seamless Integration There are two types of seamless IPP integrations:
Automatic IPPs are predefined in your merchant configuration. Consumers are prompted to choose from various installment programs offered in the seamless iframe. These programs are retrieved with an initial payment request. This request must contain your Merchant Account ID (MAID). With your MAID, Wirecard Payment Gateway checks if "onus" and "IPP" are enabled for your merchant account, so make sure that your merchant account has been set up for IPP by merchant support.
Workflow
You can customize for each payment individually which IPPs are to be displayed on your payment page. The consumer selects IPP options directly
on your payment page, but not in the seamless iframe. You provide the selected IPP details ( As the IPP options are not part of the seamless iframe, you are fully responsible for IPP selection handling. For that purpose, you have to
Workflow
|
Which of the following is a limitation of the planning process at Wirecard Check all that apply
zusammenhängende Posts
Urheberrechte © © 2024 nguoilontuoi Inc.
