Wirecard Payment Page v1

Wirecard’s Payment Page solutions handle the payment method selection as well as the collection of payment details or consumer redirects to alternative payment provider sites. With this solution, the merchant is only required to conform to a limited PCI scope (self-questionnaire A).

Wirecard Payment Page v1 is available in three formats:

  • Hosted Payment Page (HPP)

  • Embedded Payment Page (EPP)

  • Seamless Integration

Hosted Payment Page

Introduction

The Hosted Payment Page (HPP) integration redirects the consumer from the merchant’s site to the payment page along with information about the transaction and a secure digital signature.

The payment page integration requires the function call (along with information about the transaction and a secure digital signature) of the provided JavaScript library. The URL for the library varies depending on the installation domain, i.e. https://www.somedomain.com/engine/hpp/paymentPageLoader.js

Please contact merchant support for the exact URL.
Credit Card Payment

Merchants using HPP can offer credit card payments via a hyperlink from their own newsletter.

Hosted Payment Page Checkout Scheme
HPP Checkout Flow
Figure 3. Hosted Payment Page: Scheme of checkout flow
Hosted Payment Page Workflow

The Hosted Payment Page (HPP) provides a generic workflow available for various payment methods.

The following workflow mainly describes the flow of a credit card payment. For alternative payment methods (e.g. PayPal), there will be an additional re-direct to a provider.
HPP Workflow
Figure 4. Hosted Payment Page: Credit card payment flow
  1. Consumer checks out with the purchased goods/services.

  2. Merchant system redirects to the Hosted Payment Page URL with a digitally signed payment request.

  3. Wirecard Payment Gateway validates the signature and returns the list of payment methods for which the merchant has been configured with the associated redirect URL.

  4. The Hosted Payment Page displays the payment methods from which the consumer may choose. Depending on the chosen payment method and the respective specifics of this payment method, the Hosted Payment Page then displays the relevant input fields.

    This payment method selection may optionally be skipped based on the merchant’s account configuration.
  5. The Hosted Payment Page posts the payment transaction to the Wirecard Payment Gateway.

  6. Wirecard Payment Gateway processes the payment with the respective financial institution.

  7. Wirecard Payment Gateway returns the final response to the payment page, which is a digitally signed response message.

  8. The payment page posts the digitally signed response back to the merchant’s success or failure URL.

  9. Optionally, the merchant’s system validates the signature, and decodes the response message.

  10. Finally, the consumer (the consumer’s browser) is redirected to the merchant’s success or failure shop page by the payment page response.

 

 

 

Hosted Payment Page Integration
Hosted Payment Page with Payment Method Selection

Integration is as easy as including one JavaScript library into the merchant’s checkout page:

<script src=" https://api-test.wirecard.com/engine/hpp/paymentPageLoader.js" type="text/javascript"></script>

Specification of the payment data:

var requestedData = {
  merchant_account_id: "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
  request_id: "c68b9039-968d-1c6b-d9f6-27e9ab2bcb3e",
  request_time_stamp: "20150226084718",
  payment_method: "creditcard",
  transaction_type: "authorization",
  requested_amount: "2.56",
  requested_amount_currency: "EUR",
  locale: "en",
  request_signature: "e44730486d180cca590bc2e8dea22bd175395636a37b0da0ef785"
}

A function call of that library provides the payment functionality:

WirecardPaymentPage.hostedPay(requestedData);

Or call a different name library with the same functionality:

ElasticPaymentPage.hostedPay(requestedData);
Sample: Redirecting to the Hosted Payment Page
Basic HTML Sample
<html>
<head>
  <title>example 01</title>
  <script src="https://api-test.wirecard.com/engine/hpp/paymentPageLoader.js" type="text/javascript"></script>
  <script>
    function pay() {
      var requestData = {
        "request_id": "4d87f443-423c-6b13-e609-cc8b59c32d6b",
        "request_time_stamp": "20160817140742",
        "merchant_account_id": "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
        "transaction_type": "auto-sale",
        "requested_amount": "0",
        "requested_amount_currency": "EUR",
        "request_signature": "283a346275444f3f4fbbbd7e3bcf815b41c4edf1a2531208e201fab12a9b0d53",
        "payment_method": "creditcard",
        "first_name": "John",
        "last_name": "Doe"
      };
      WirecardPaymentPage.hostedPay(requestData);
    }
  </script>
</head>
<body>
  <h1>example 01</h1>
  <form>
    <input type="button" value="Pay" onClick="pay()">
  </form>
</body>
</html>
Basic HTML Sample with Credit Card Form
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <title>
      Demo shop
    </title>
    <script src="https://api-test.wirecard.com/engine/hpp/paymentPageLoader.js" type="text/javascript"></script>
  </head>
  <body>
    <form>
      <input id="wirecard_pay_btn" type="button" onclick="pay()" value="Pay Now"> <script type="text/javascript">
        function pay() {
        var requestedData = {
            merchant_account_id: "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
            request_id: "c68b9039-968d-1c6b-d9f6-27e9ab2bcb3e",
            request_time_stamp: "20150226084718",
            payment_method: "creditcard",
            transaction_type: "purchase",
            requested_amount: "2.56",
            requested_amount_currency: "EUR",
            locale: "en",
            request_signature: "kg44730486d159df0bc2e8dea22bd175395636a37b0da0ef785"
         }
        WirecardPaymentPage.hostedPay(requestedData);
        }
      </script>
    </form>
  </body>
</html>
Basic HTML Sample with PayPal Checkout Portal
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <title>
      Demo shop
    </title>
<script src="https://api-test.wirecard.com/engine/hpp/paymentPageLoader.js" type="text/javascript"></script>
  </head>
   <body>
    <form>
      <input id="wirecard_pay_btn" type="button" onclick="pay()" value="Pay Now"> <script type="text/javascript">
      function pay() {
         var requestedData = {
            merchant_account_id: "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
            request_id: "c68b9039-968d-1c6b-d9f6-27e9ab2bcb3e",
            request_time_stamp: "20150226084718",
            payment_method: "paypal",
            transaction_type: "debit",
            requested_amount: "2.56",
            requested_amount_currency: "EUR",
            locale: "en",
            request_signature: "d730486d159df0bc2e8dea22bd175395636a37b0da0ef785"
         }
       WirecardPaymentPage.hostedPay(requestedData);
       }
      </script>
    </form>
  </body>
</html>
Please note that only the fields payment_method and transaction_type differ.

Embedded Payment Page

Introduction

With this type of integration, the payment page is displayed in overlay directly on the merchant’s checkout page. Redirection is not needed to select a payment method or to enter payment details. This type of integration allows for a more comfortable consumer’s experience. The consumer feels as though the payment page is still an integral part of the merchant’s site.

The Embedded Payment Page (EPP) integration is the same as for the Hosted Payment Page – it involves a (different) function call from the same JavaScript library.

Embedded Payment Page Overview
Figure 5. Embedded Payment Page: Scheme of checkout flow
Embedded Payment Page Workflow

The following image shows the Embedded Payment Page workflow.

Embedded Payment Page Workflow
Figure 6. Embedded Payment Page workflow
  1. Consumer checks out with the purchased goods/services.

  2. Wirecard Payment Gateway validates the signature and returns the list of payment methods for which the merchant has been configured with the associated redirect URL.

  3. The payment page displays the payment methods from which the consumer may choose. Depending on the chosen payment method and the respective specifics of this payment method, the payment page then displays the relevant input fields.

    This payment method selection may optionally be skipped based on the merchant’s account configuration.
  4. The payment page posts the payment transaction to the Wirecard Payment Gateway.

  5. The Wirecard Payment Gateway processes the payment with the respective financial institution.

  6. The Wirecard Payment Gateway returns the final response to the payment page, which is a digitally signed response message.

  7. The payment page posts the digitally signed response back to the merchant’s success or failure URL.

  8. Optionally, the merchant’s system validates the signature, and decodes the response message. Finally, the consumer (the consumer’s browser) is redirected to the merchant’s cancel or processing page and then onto success or failure page by the pPayment page response.

Embedded Payment Page Integration

From a technical point of view, merchants just include one JavaScript library:

<script src="https://api-test.wirecard.com/engine/hpp/paymentPageLoader.js" type="text/javascript"></script>

A function call of that library provides the payment functionality:

WirecardPaymentPage.embeddedPay(requestedData);

Or call a different name library with same functionality:

ElasticPaymentPage.embeddedPay(requestedData);
Sample: Showing the Embedded Payment Page
Basic HTML Sample
<html>
    <head>
        <title>example 01</title>
        <script src=" https://api-test.wirecard.com/engine/hpp/paymentPageLoader.js" type="text/javascript"/>
        <script>
function pay() {
var requestData = {
"request_id" : "4d87f443-423c-6b13-e609-cc8b59c32d6b",
"request_time_stamp" : "20160817140742",
"merchant_account_id" : "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
"transaction_type" : "auto-sale",
"requested_amount" : "0",
"requested_amount_currency" : "EUR",
"request_signature" : "283a346275444f3f4fbbbd7e3bcf815b41c4edf1a2531208e201fab12a9b0d53",
"payment_method" : "creditcard",
"first_name" : "John",
"last_name" : "Doe"
};
WirecardPaymentPage.embeddedPay(requestData);
}
        </script>
    </head>
    <body>
        <h1>example 01</h1>
        <form>
            <input type="button" value="Pay" onClick="pay()">
            </form>
        </body>
    </html>
Basic HTML Sample with Credit Card Form
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
    <title>Demo shop</title>
    <script src="https://api-test.wirecard.com/engine/hpp/paymentPageLoader.js" type="text/javascript"></script>
</head>
<body>
    <input id="wirecard_pay_btn" type="button" onclick="pay()" value="Pay Now"/>
    <script type="text/javascript">
        function pay() {
          var requestedData = {
          merchant_account_id: "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
          request_id: "c68b9039-968d-1c6b-d9f6-27e9ab2bcb3e",
          request_time_stamp: "20150226084718",
          payment_method: "creditcard",
          transaction_type: "purchase",
          requested_amount: "2.56",
          requested_amount_currency: "EUR",
          locale: "en",
          request_signature: "e44730486d180cca590bc2e8dea22bd175395636a37b0da0ef785"
          }
         WirecardPaymentPage.embeddedPay(requestedData);
        }
    </script>
</body>
</html>

Seamless Integration

Seamless integration provides a possibility to incorporate Wirecard’s payment form into the merchant’s checkout page for merchants who want to

  • avoid browser redirects to Wirecard’s payment pages and back to the shop during the checkout process.

  • take care of payment selection process and fully control the look and feel of the payment form themselves.

  • provide a more sophisticated checkout flow that includes first collecting payment data and then allowing the consumer to review the order one more time before confirming the payment.

This approach provides a seamless shopping experience for web-shoppers, while the technical solution categorizes the merchant into the least demanding PCI-DSS category. The main advantages of the Seamless solution are:

  • Seamless user experience - the payment form appears as an integral part of merchant’s checkout page.

  • Possibility to decouple entering payment data from the actual payment - it is possible to display a summary page in between.

  • No in-browser redirects, no external processing pages, no pop-up windows. The only redirect to an external page will happen if credit card payment requires 3D-Secure verification.

  • Only the simple Self-Assessment-Questionnaire "A" (SAQ-A) is required for the merchant to be PCI-DSS compliant.

Seamless Integration Workflow

To ensure a seamless and PCI compliant integration, Wirecard serves the complete payment form as an HTML iFrame, which ensures that attacker or malicious scripts will not have access to data entered on the merchant’s page. The form is then submitted directly to Wirecard’s servers over a secure TLS channel, so the data is securely transported. The high-level diagram below shows the checkout flow with the optional order summary page between the payment data collection page and the actual payment:

Seamless Integration Workflow
Figure 7. Seamless Integration Workflow
Integration

Integration is done via JavaScript library which merchants include in their checkout page:

<script src="https://api-test.wirecard.com/engine/hpp/paymentPageLoader.js" type="text/javascript"></script>

There are three functions provided by the library:

You can optionally use ElasticPaymentPage instead of WirecardPaymentPage, e.g. call ElasticPaymentPage.seamlessRenderForm().
Render the form
WirecardPaymentPage.seamlessRenderForm({
    requestData : requestData, (1)
    wrappingDivId : "seamless-target", (2)
    onSuccess : processSucceededResult (3)
    onError : processErrorResult (4)
});

Renders the form. Parameters are

1 requestData: request data object, same as for Hosted Payment Page and similar to REST API integration
2 wrappingDivId: ID of the HTML element where the form will be rendered
3 onSuccess: callback on successful render
4 onError: callback if an error occurred
Submit the form
WirecardPaymentPage.seamlessSubmitForm({
    requestData : requestData, (1)
    onSuccess : processSucceededResult, (2)
    onError : processErrorResult (3)
});

Submits the form. Parameters are

1 requestData: additional request data (optional)
2 onSuccess: callback on successful form submission
3 onError: callback when an error occurred submitting the form
Submit the payment request
WirecardPaymentPage.seamlessPay({
    requestData : requestData, (1)
    onSuccess : processSucceededResult, (2)
    onError : processErrorResult (3)
});

Submits the payment request. Parameters are

1 requestData: request data object, same as for Hosted Payment Page and similar to REST API integration
2 onSuccess: callback on successful payment request
3 onError: callback if an error occurred submitting the payment request
The only parameter of the functions in case of both success and error is response.
Card Form Integration

This use-case covers the payment form displayed directly on the merchant’s checkout page for a seamless user experience (no browser redirects).

Render Form

Merchant renders the form into element on their checkout page. The transaction details are specified in requestData. The element is identified by wrappingDivId parameter.

var requestData = {
  "request_id" : "217c3832-8575-c1d5-0e3a-2fa08003b0fd",
  "request_time_stamp" : "20190403095835",
  "merchant_account_id" : "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
  "transaction_type" : "purchase",
  "requested_amount" : "2.00",
  "requested_amount_currency" : "EUR",
  "ip_address" : "127.0.0.1",
  "request_signature" : "43fd8c261a8fdad693024c7cc009239ad344f1e5716de0c3163237b5392d5700",
  "payment_method" : "creditcard"
};
WirecardPaymentPage.seamlessRenderForm({
  requestData : requestData,
  wrappingDivId : "seamless-target",
  onSuccess : processSucceededResult,
  onError : processErrorResult
});
Use a unique Request ID for each request.
Transaction Data Received from onSuccess Callback of seamlessRenderForm()
{
  "ip_address": "127.0.0.1",
  "merchant_account_id": "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
  "request_id": "217c3832-8575-c1d5-0e3a-2fa08003b0fd",
  "requested_amount": "2.00",
  "requested_amount_currency": "EUR",
  "status_code_1": "201.0000",
  "status_description_1": "The resource was successfully created.",
  "status_severity_1": "information",
  "transaction_id": "5ff1cf52-8471-11e5-95ea-005056b13376",
  "transaction_state": "success",
  "transaction_type": "check-signature"
}
Submit Form

Merchant assigns the call function to a pay button on the checkout page. requestData are optional when submitting form. They will be merged with data from the first step. Form input is validated before the submit.

WirecardPaymentPage.seamlessSubmitForm({
  onSuccess : processSucceededResult,
  onError : processErrorResult
});
Transaction Data Received from onSuccess Callback of seamlessSubmitForm()
{
  "api_id": "elastic-api",
  "authorization_code": "153620",
  "completion_time_stamp": "20190406103540",
  "first_name": "John",
  "ip_address": "127.0.0.1",
  "last_name": "Doe",
  "masked_account_number": "444433******1111",
  "merchant_account_id": "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
  "payment_method": "creditcard",
  "provider_transaction_id_1": "8ee6e543-c96f-459a-a379-50d0e9152fd3",
  "request_id": "217c3832-8575-c1d5-0e3a-2fa08003b0fd",
  "requested_amount": "2.00",
  "requested_amount_currency": "EUR",
  "self": "https://test-api.wirecard.com:9000/engine/rest/merchants/61e8c484-dbb3-4b69-ad8f-706f13ca141b/payments/1fe8a33a-8472-11e5-95ea-005056b13376",
  "status_code_1": "201.0000",
  "status_description_1": "3d-acquirer:The resource was successfully created.",
  "status_severity_1": "information",
  "token_id": "4186409015611111",
  "transaction_id": "1fe8a33a-8472-11e5-95ea-005056b13376",
  "transaction_state": "success",
  "transaction_type": "purchase"
}
Decoupling Card Data Collection from Payment

When the merchant decides to display a recap order page between the payment data collection page and actually submitting the payment, the merchant may use the payment form to perform a:

  • Zero authorization transaction that may later be referenced by a regular authorization or purchase. The advantage for credit card payments is that a zero authorization transaction is confirmed by an issuer and the CVC is verified.

  • Tokenization-only transaction. A token (non-sensitive data) is returned to the merchant that can be used for a real authorization or purchase later.

In either case, sensitive payment data will not touch any of the merchant’s systems.

The difference to the previous scenario is that an authorization-only transaction type with a zero amount is used instead of a purchase transaction type (tokenization transaction type may be used for a similar effect), and the real fund booking only comes in the third (additional) step. The payment form is displayed directly on the merchant’s checkout page.

Render Form

The merchant renders the form into an element on their checkout page. The transaction details are specified in requestData. The element is identified by wrappingDivId parameter.

var requestData = {
  "request_id" : "217c3832-8575-c1d5-0e3a-2fa08003b0fd",
  "request_time_stamp" : "20190403095835",
  "merchant_account_id" : "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
  "transaction_type" : "authorization-only",
  "requested_amount" : "0",
  "requested_amount_currency" : "EUR",
  "ip_address" : "127.0.0.1",
  "request_signature" : "43fd8c261a8fdad693024c7cc009239ad344f1e5716de0c3163237b5392d5700",
  "payment_method" : "creditcard"
};
WirecardPaymentPage.seamlessRenderForm({
  requestData : requestData,
  wrappingDivId : "seamless-target",
  onSuccess : processSucceededResult,
  onError : processErrorResult
});
Use a unique Request ID for each request.
Transaction Data Received from onSuccess Callback of seamlessRenderForm()
{
  "ip_address": "127.0.0.1",
  "merchant_account_id": "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
  "request_id": "217c3832-8575-c1d5-0e3a-2fa08003b0fd",
  "requested_amount": "0",
  "requested_amount_currency": "EUR",
  "status_code_1": "201.0000",
  "status_description_1": "The resource was successfully created.",
  "status_severity_1": "information",
  "transaction_id": "5ff1cf52-8471-11e5-95ea-005056b13376",
  "transaction_state": "success",
  "transaction_type": "check-signature"
}
Submit Form

The merchant will assign call of the function to a pay button on their checkout page. requestData are optional when submitting the form. They will be merged with data from the first step. Form input is validated before the submit.

WirecardPaymentPage.seamlessSubmitForm({
  onSuccess : processSucceededResult,
  onError : processErrorResult
});
Transaction Data Received from onSuccess Callback of seamlessSubmitForm()
{
   "api_id":"elastic-api",
   "authorization_code":"153620",
   "completion_time_stamp":"20190406103540",
   "first_name":"John",
   "ip_address":"127.0.0.1",
   "last_name":"Doe",
   "masked_account_number":"444433******1111",
   "merchant_account_id":"61e8c484-dbb3-4b69-ad8f-706f13ca141b",
   "payment_method":"creditcard",
   "provider_transaction_id_1":"8ee6e543-c96f-459a-a379-50d0e9152fd3",
   "request_id":"217c3832-8575-c1d5-0e3a-2fa08003b0fd",
   "requested_amount":"0",
   "requested_amount_currency":"EUR",
   "self":"https://test-api.wirecard.com:9000/engine/rest/merchants/61e8c484-dbb3-4b69-ad8f-706f13ca141b/payments/1fe8a33a-8472-11e5-95ea-005056b13376",
   "status_code_1":"201.0000",
   "status_description_1":"3d-acquirer:The resource was successfully created.",
   "status_severity_1":"information",
   "token_id":"4186409015611111",
   "transaction_id":"1fe8a33a-8472-11e5-95ea-005056b13376",
   "transaction_state":"success",
   "transaction_type":"authorization-only"
}
Actual Payment

The merchant can now reference an existing authorization-only transaction to do a payment without further consumer involvement. The merchant may also do this using the function from Wirecard’s JavaScript library from the browser.

var requestData = {
  "request_id" : "679047dc-8a4d-657b-91dc-df6d80cd6a10",
  "request_time_stamp" : "20190403101310",
  "merchant_account_id" : "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
  "transaction_type" : "purchase",
  "requested_amount" : "12",
  "requested_amount_currency" : "EUR",
  "ip_address" : "127.0.0.1",
  "request_signature" : "ea468004287bf191a43b4c5ac33e38d5f035050ad784cad293646c1533e7fc48",
  "payment_method" : "creditcard",
  "parent_transaction_id" : "26c14051-8213-11e5-a96e-0050b667eb91"
};
WirecardPaymentPage.seamlessPay({
  requestData : requestData,
  onSuccess : processSucceededResult,
  onError : processErrorResult
});
Use a unique Request ID for each request.
Transaction Data Received from onSuccess Callback of seamlessPay()
{
  "api_id": "elastic-api",
  "authorization_code": "153620",
  "completion_time_stamp": "20190406103540",
  "first_name": "John",
  "ip_address": "127.0.0.1",
  "last_name": "Doe",
  "masked_account_number": "444433******1111",
  "merchant_account_id": "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
  "payment_method": "creditcard",
  "provider_transaction_id_1": "8ee6e543-c96f-459a-a379-50d0e9152fd3",
  "request_id": "217c3832-8575-c1d5-0e3a-2fa08003b0fd",
  "requested_amount": "12",
  "requested_amount_currency": "EUR",
  "self": "https://test-api.wirecard.com:9000/engine/rest/merchants/61e8c484-dbb3-4b69-ad8f-706f13ca141b/payments/1fe8a33a-8472-11e5-95ea-005056b13376",
  "status_code_1": "201.0000",
  "status_description_1": "3d-acquirer:The resource was successfully created.",
  "status_severity_1": "information",
  "token_id": "4186409015611111",
  "transaction_id": "1fe8a33a-8472-11e5-95ea-005056b13376",
  "transaction_state": "success",
  "transaction_type": "purchase"
}
Validation, Language and Custom Templates
Form Validation

Merchant can request form validity by using function.

The only parameter is the name of the callback function.

WirecardPaymentPage.seamlessFormIsValid({
 onValidationResult : processValidationResult
});

Merchant can validate the form input anytime calling function.

The only parameter is the name of the callback function. Otherwise, the form is validated always on form submit.

WirecardPaymentPage.seamlessValidateForm({
 onValidationResult : processValidationResult
});
Change Language

Merchant can change form’s locale using function.

The only parameter is the language ISO code.

WirecardPaymentPage.seamlessChangeLocale("en");
Custom Templates

Merchants are able to specify their own custom templates to be used instead of Wirecard’s default payment form. The template consists of HTML content, CSS and JavaScript parts. The following template is an example of a merchant’s custom template that uses bootstrap and form validation libraries. First, the HTML part is inserted into the <body> tag of the page, so it is a simple HTML form:

<h3 data-i18n="cc_form_title">Billing information</h3>
<form id="seamless-form" data-wd-validate-form="true" th:object="${payment}">
  <div class="row">
    <div class="form-group col-xs-12">
      <div class="card-types btn-group" data-toggle="buttons">
        <label class="btn btn-default active"> <input type="radio"
          class="ee-request-nvp" name="card_type" value="visa"
          checked="checked" data-fv-wdcardtype="true"
          data-fv-wdcardtype-message="select_valid_card_type"
          data-fv-wdcardtype-creditcardfield="account_number" /> <img
          src="https://upload.wikimedia.org/wikipedia/commons/thumb/5/5e/Visa_Inc._logo.svg/1280px-Visa_Inc._logo.svg.png"
          alt="Visa" />
        </label> <label class="btn btn-default"> <input type="radio"
          class="ee-request-nvp" name="card_type" value="mastercard" /> <img
          src="https://lh5.googleusercontent.com/-_o1E3Ie8C8Y/U1YW_49rhBI/AAAAAAAAAbI/vGfq1_kakSU/w800-h800/mastercard-logo-in-jokerman-font.png"
          alt="Mastercard" />
        </label> <label class="btn btn-default"> <input type="radio"
          class="ee-request-nvp" name="card_type" value="diners" /> <img
          src="http://www.golf.co.nz/uploads/diners-logo-transparent.png"
          alt="Diners" />
        </label>
      </div>
    </div>
  </div>
  <div class="row">
    <div class="col-sm-8">
      <div class="form-group">
        <input type="text" class="form-control ee-request-nvp"
          id="account_number" name="account_number" placeholder="Card number"
          data-i18n="card_number" data-fv-wdcreditcard="true"
          data-fv-wdcreditcard-message="enter_creditcard_number"
          data-fv-wdcreditcard-cardtypefield="card_type"
          data-fv-wdcreditcard-cvvfield="card_security_code"
          data-fv-wdcreditcard-allowedcardtypes="visa,mastercard,diners"
          data-fv-onsuccess="FormValidation.WDHelper.onCardNumberSuccess"
          data-fv-onerror="FormValidation.WDHelper.onCardNumberError" />
      </div>
    </div>
    <div class="col-sm-4">
      <div class="form-group">
        <input type="text" class="form-control ee-request-nvp"
          id="card_security_code" name="card_security_code" placeholder="CVV"
          data-fv-wdcvv="true" data-fv-wdcvv-message="enter_cvv"
          data-fv-wdcvv-creditcardfield="account_number"
          data-i18n="card_security_code" />
      </div>
    </div>
  </div>
  <div id="expiry-date-div" class="row">
    <div class="col-sm-8"></div>
    <div class="col-sm-2">
      <div class="form-group">
        <input type="number" class="form-control ee-request-nvp"
          id="expiration_month" name="expiration_month" placeholder="Month"
          data-i18n="expiration_month" data-fv-notempty="true"
          data-fv-notempty-message="enter_value" data-fv-wdexpirymonth="true"
          data-fv-wdexpirymonth-message="invalid_expiry_date"
          data-fv-wdexpirymonth-yearfield="expiration_year" />
      </div>
    </div>
    <div class="col-sm-2">
      <div class="form-group">
        <input type="number" class="form-control ee-request-nvp"
          id="expiration_year" data-fv-notempty="true"
          data-fv-notempty-message="enter_value" data-fv-wdexpiryyear="true"
          data-fv-wdexpiryyear-message="invalid_expiry_date"
          data-fv-wdexpiryyear-yearscount="20"
          data-fv-wdexpiryyear-monthfield="expiration_month"
          name="expiration_year" placeholder="Year"
          data-i18n="expiration_year" />
      </div>
    </div>
  </div>
  <div class="row">
    <div class="col-sm-6">
      <div class="form-group">
        <input type="text" class="form-control ee-request-nvp"
          id="first_name" name="first_name"
          placeholder="Cardholder first name" data-i18n="first_name"
          th:value="*{accountHolder} ? *{accountHolder.firstName}" />
      </div>
    </div>
    <div class="col-sm-6">
      <div class="form-group">
        <input type="text" class="form-control ee-request-nvp"
          id="last_name" name="last_name" placeholder="Cardholder last name"
          data-fv-notempty="true" data-fv-notempty-message="enter_value"
          data-i18n="last_name"
          th:value="*{accountHolder} ? *{accountHolder.lastName}" />
      </div>
    </div>
  </div>
</form>

 

The HTML part may be completed with a CSS stylesheet:

body {
  font-family: Verdana;
  font-size: 12px;
  padding: 20px;
}
input {
  width: 100%;
}
.btn {
  outline: none !important;
}
.card-types .btn {
  height: 40px
}
.card-types .btn img {
  width: 40px;
}
.card-types .form-control-feedback {
  right: -40px !important;
  top: 1px !important;
}

Each merchant may provide multiple templates and specify which one to use when rendering the Seamless form.

Please contact merchant support in order to set up custom templates.
Seamless Configuration UI

The Seamless Configuration UI endpoint has been created for the purpose of changing a Seamless template online and previewing it just in time.

After browser authentication, the Seamless Configuration UI is accessible on https://api-test.wirecard.com/engine/rest/config/seamless/ui

The following view should be displayed, once access is granted:

Seamless Templates Configuration MAID

When an existing merchant is selected, all the merchant’s related templates should be loaded automatically from the server via REST API. The list of the merchant’s configured templates is displayed on the left-side menu. Template-specific details are displayed on the right in tabs.

Template Details
Production Deployment Process

Currently, the Seamless UI editor is available only on the TEST environment. Therefore, once a template has been created by the merchant and is ready for production, the merchant has to export the theme and send it to merchant support to upload it to the PRODUCTION environment.

Resources Management

The screenshot below shows the Template Resources (JS and CSS) configuration. Selecting resources is optional. A resource should be added just in case it is required by a particular template.

To select a resource, double-click on it in the Available Resources list on top (or select it and use arrows between list boxes). To deselect a resource, double-click on it in the bottom list of Selected Resources. To change the order, use the arrows next to the Selected Resources list.

The order is important when loading libraries with dependencies.

Template Resources
Translation Management

A template-specific i18n configuration can be made within the Template Translations tab. Here, new translations can be created or existing ones updated/deleted. Changes are applied once the whole template is successfully saved. The user can add/paste all required translations there (for multiple locales) at once.

Each i18n configuration must contain a language code  (2-letters code in square brackets) at the beginning followed by all required key=value translations mappings separated by a new line. The language code is case-insensitive. There can be just one translation key per locale. The translation key can contain letters, numerics, dashes or underscores only.

Template Translations

Seamless i18n

Translations are maintained by the jquery.i18n.properties library and its EE extension, ee.i18n library. Each element containing a data-i18n attribute is automatically translated according to the locale (2-letters language code) specified within the payment request. The value of the data-i18n attribute represents a translation key. Please see the list of current default translation keys and associated translations below.  They are used within the default Seamless template. It is possible to override all these translations as well as specify the new ones when configuring a new template. It is also possible to define an arbitrary language code.

Default Translations
# default language (English)
card_number=Card number
expiry_date=Valid until
year=Year
month=Month
invalid_expiry_date=Please enter a valid expiry date
first_name=First name
last_name=Last name
enter_value=Please enter a value
select_valid_card_type=Please enter a valid credit card type
enter_creditcard_number=Please enter the valid and confirmed credit card number
enter_cvv=Please enter a valid security code (CVV)

[de]
card_number=Kartennummer
first_name=Vorname
last_name=Nachname
expiry_date=Gültig bis
year=Jahr
month=Monat
enter_value = Bitte geben Sie einen Wert ein
enter_creditcard_number = Bitte geben Sie die gültige und bestätigte Kreditkartennummer an
select_valid_card_type = Bitte geben Sie den gültigen Kreditkartentyp an
invalid_expiry_date = Bitte gültiges Ablaufdatum angeben
enter_cvv = Bitte geben Sie den gültigen Sicherheitscode (CVV) an

[es]
card_number=Número de tarjeta
first_name=Nombre
last_name=Apellidos
expiry_date=Válido hasta
year = Año
enter_value = Introduzca un valor
enter_creditcard_number = Indique una tarjeta de crédito válida y confirmada
select_valid_card_type = Indique un tipo de tarjeta de crédito válido
invalid_expiry_date = Indique una fecha de caducidad válida
enter_cvv = Indique el código de seguridad (CVV) válido

[fr]
card_number=Numéro de carte
first_name=Prénom
last_name=Nom
expiry_date=Date d''expiration
year = Année
enter_value = Veuillez saisir une valeur
enter_creditcard_number = Veuillez saisir un numéro de carte de crédit valide et confirmé
select_valid_card_type = Veuillez saisir un type de carte de crédit valide
invalid_expiry_date = Veuillez saisir une date d’expiration valide
enter_cvv = Veuillez saisir un code de sécurité valide (CVV)

[it]
card_number=Numero di carta
first_name=Nome
last_name=Cognome
expiry_date=Valido fino a
year = Anno
enter_value = Immettere un valore
enter_creditcard_number = Immettere un numero di carta di credito valido e confermato
select_valid_card_type = Immettere un tipo di carta di credito valido
invalid_expiry_date = Immettere una data di scadenza valida
enter_cvv = Immettere un codice di sicurezza valido (CVV)

[nl]
card_number=Kaartnummer
first_name=Voornaam
last_name=Achternaam
expiry_date=Geldig tot
year = Jaar
enter_value = Voer een waarde in
enter_creditcard_number = Voer een geldig en bevestigd creditcardnummer in
select_valid_card_type = Voer een geldig creditcardtype in
invalid_expiry_date = Voer een geldige einddatum in
enter_cvv = Voer de geldige veiligheidscode (CVV) in
Template PREVIEW

To preview the selected and saved template press the Eye Symbol button. A couple of details need to be entered before the preview is shown - such as dimensions, locale or currency (currency is necessary just in case the selected template needs the merchant’s configured card types model).

Template Preview 1

The template preview is provided by the endpoint {URL}/engine/rest/seamless/renderform/preview/{merchantAccountId}/{paymentMethodId}/{templateName}

and handled by

com.ep.engine.controller.SeamlessPaymentController

When the appropriate GET request is performed, the rendered template view is returned and it looks exactly as if it would be rendered via /engine/rest/seamless/renderform endpoint

This endpoint is secured by a basic authentication and the role ROLE_CONFIG_SEAMLESS

Template Preview 2
Import/Export Template

The selected template can be exported to a .json file by clicking the export button Export Symbol. The exported template can then be imported within different environments (integration, test, production, …​) by clicking on + Add a template > Import from JSON file and selecting the particular .json file from the local storage.

Template Import
Clone Default Template

The default credit card template default-cc-template can be cloned to the current merchant account’s Seamless configuration by clicking on + Clone default CC template. This feature can help in situations when just few changes within the default template would be needed. Once the default template is cloned, the configuration can be finished much easier.

Default Seamless Template

Merchants have two options with which Seamless can be shown:

  • Manual Card Brand Selection

  • Automatic Card Brand Recognition (default)

If there is a need to use manual selection, please send template_name in the request.

Manual Card Brand Selection
template_name = default-cc-template
Automatic Card Brand Recognition
template_name = default-cc-auto

Payment Page Fields

Most of the fields from REST API are also available for Hosted Payment Page (HPP), Embedded Payment Page (EPP) and Seamless integration, differing only in the usage of an underscore instead of a hyphen.

The following table describes the fields that may appear in the HTML form in case of Hosted Payment Page (HPP) or as data for a JavaScript call in case of Embedded Payment Page (EPP) or Seamless integration.

Request Fields
Field Cardinality Datatype Size Description

request_time_stamp

Mandatory

yyyyMMddHHmmss

14

The UTC time-stamp that represents the request.

request_signature

Mandatory

Alphanumeric

64

Refer to SHA-256 request signature.

merchant_account_id

Mandatory

Alphanumeric

36

A unique identifier assigned for every Merchant Account.

request_id

Mandatory

Alphanumeric

64

The unique string that the merchant sends with every transaction in order to uniquely identify it. The merchant system can subsequently request the status or existence of a transaction using this identifier.

entry_mode

Optional

Alphanumeric

n/a

The method in which the account holder information was collected. Possible values are:

Value Meaning

empty

unknown source

ecommerce

collected over the internet

mcommerce

collected over mobile devices

mail-order

collected over mail order

telephone-order

collected over telephone

pos

collected by the primary payment instrument

periodic_type

Optional

Alphanumeric

n/a

Indicates how and why a payment occurs more than once. Possible values include installment: one in a set that completes a financial transaction and recurring: one in a set that occurs repeatedly, such as a subscription.

sequence_type

Optional

Alphanumeric

n/a

Used in conjunction with periodic_type to indicate the sequence. Possible values include first: first transaction in a set, recurring: subsequent transactions in the set, final: the last transaction in the set.

transaction_type

Mandatory

Alphanumeric

30

A unique identifier assigned for every transaction type.

requested_amount

Mandatory

Decimal

11,2

The only amount that accompanies the transaction when it is created and/or requested. In the case of a sale or refund, this is what the merchant requests. In the case of a chargeback, this is the amount that is being contested.

requested_amount_currency

Mandatory

Alphanumeric

3

The currency in which a transaction is originally completed.

first_name

Optional

Alphanumeric

32

The first name of the account holder.

last_name

Mandatory

Alphanumeric

32

The last name of the account holder.

token_id

Optional   - Or Card Number

Numeric

36

A unique identifier assigned for every card token. This is a surrogate value for the primary account number.

card_type

Mandatory   - Or Card Token

Alphanumeric

15

A card scheme accepted by the processing system. This includes physically issued cards.

account_number

Mandatory   - Or Card Token

Numeric

36

The  embossed or encoded number that identifies the card issuer to which a transaction is to be routed and the account to which it is to be charged unless specific instructions indicate otherwise. In the case of a credit card, this is the primary account number.

expiration_month

Mandatory   - Or Card Token

Numeric

2

The 2-digit representation of the expiration month of the card account.

expiration_year

Mandatory   - Or Card Token

Numeric

4

The 4-digit representation of the expiration year of the card account.

card_security_code

Optional   - Depending on merchant account settings

Numeric

4

A security feature for credit or debit card transactions, providing increased protection against credit card fraud. The Card Security Code is located on the back of Mastercard, Visa and Discover credit or debit cards and is typically a separate group of 3 digits to the right of the signature strip. On American Express cards, the Card Security Code is a printed, not embossed,  group of four digits on the front towards the right.

redirect_url

Optional

Alphanumeric

256

The URL where the account holder will be redirected to following transaction completion.

ip_address

Optional

Alphanumeric

15

The IP address of the cardholder as recorded by the entity receiving the transaction attempt from the cardholder.

email

Optional

Alphanumeric

64

The email address of the account holder.

phone

Optional

Alphanumeric

32

The phone number of the account holder.

order_detail

Optional

Alphanumeric

256

Merchant-provided string to store the order detail for the transaction.

order_number

Optional

Alphanumeric

64

Merchant-provided string to store the order detail for the transaction.

merchant_crm_id

Optional

Alphanumeric

64

The merchant CRM ID for the account holder.

field_name_n[1-10]

Optional

Alphanumeric

36

Text used to name the transaction custom field. Possible values for n can be in the range from 1 to 10.

field_value_n[1-10]

Optional

Alphanumeric

256

Used with a key, the content used to define the value of the transaction custom field. Possible values for n can be in the range from 1 to 10.

notification_url_n[1-3]

Optional

Alphanumeric

256

WPG uses the notification URL to inform the merchant about the outcome of the payment process. Usually the merchant provides one URL, to which WPG will send the notification to. If required, the merchant can define more than one notification URL.

notification_transaction_state_n[1-3]

Optional

Alphanumeric

12

The merchants can provide notification URLs which correspond to the transaction state. The merchants define one URL for success and one for failure.
If the merchants want to do that, they must use both fields in parallel: notification_url_n[1-3] and notification_transaction_state_n[1-3].

descriptor

Optional

Alphanumeric

64

The field which is shown on the customer’s card statement. This feature is not supported by all the acquirers. The size of this field depends on the acquirer. Please contact technical support for further clarification.

parent_transaction_id

Optional

Alphanumeric

36

A  unique identifier assigned for every parent transaction.

payment_method

Optional

Alphanumeric

15

Text used to name the payment method.

locale

Optional

Alphanumeric

6

Code to indicate which default language the payment page should be rendered in. 

device_fingerprint

Optional

Alphanumeric

4096

A device fingerprint is information collected about a remote computing device for the purpose of identification. Fingerprints can be used to fully or partially identify individual users or devices even when cookies are turned off.

processing_redirect_url

Optional

Alphanumeric

2000

The URL to which the Account Holder will be re-directed during payment processing. This is normally a page on the Merchant’s website.

cancel_redirect_url

Optional

Alphanumeric

2000

The URL to which the Account Holder will be re-directed after he has cancelled a payment. This is normally a page on the Merchant’s website.

fail_redirect_url

Optional

Alphanumeric

2000

The URL to which the Account Holder will be re-directed after an unsuccessful payment. This is normally a page on the Merchant’s website notifying the Account Holder of a failed payment often with the option to try another Payment Method.

success_redirect_url

Optional

Alphanumeric

2000

The URL to which the Account Holder will be re-directed after a successful payment. This is normally a success confirmation page on the Merchant’s website.

merchant_account_resolver_category

Mandatory

Alphanumeric

32

Configuration specific category name for automatic merchant account resolving based on logged in user or "super merchant account".

notification_transaction_url

Mandatory

Alphanumeric

2000

This field has been replaced by notification_url_n[1-3] (see above). It can still be used but it can only provide a single URL for notifications.

cryptogram_type

Optional

Alphanumeric

11

Cryptogram type enumeration – android-pay or apple-pay.

cryptogram_value

Optional

Alphanumeric

 

Cryptogram value for android or apple creditcard payments.

mandate_signature_image

Optional

Alphanumeric

 

The signature of the Mandate Transaction.

mandate_signed_city

Optional

Alphanumeric

36

The city that the Mandate was signed in.

mandate_signed_date

Optional

YYYY-MM-DD

16

The date that the Mandate was signed.

mandate_due_date

Optional

Alphanumeric

 

The date that the Mandate Transaction is due.

mandate_mandate_id

Optional

Alphanumeric

35

The Mandate ID for the Mandate Transaction.

capture_date

Optional

Alphanumeric

bank_account_bank_code

Optional

Alphanumeric

15

The national bank sorting code for national bank transfers.

bank_account_bank_name

Optional

Alphanumeric

100

The name of the consumer’s bank.

bank_account_account_number

Mandatory

Alphanumeric

34

The number designating a bank account used nationally.

bank_account_account_owner

 

 

 

Bank account owner name (not used anymore – last_name and first_name used instead).

bank_account_iban

Optional

Alphanumeric

34

The International Bank Account Number required in a Bank Transfer. It is an international standard for identifying bank accounts across national borders. The current standard is ISO 13616:2007, which indicates SWIFT as the formal registrar.

bank_account_bic

Optional

Alphanumeric

15

The Bank Identifier Code information required in a Bank Transfer.

bank_account_branch_city

Optional

Alphanumeric

64

The city that the bank is located in. Typically required for Chinese Bank Transfers.

bank_account_branch_state

Optional

Alphanumeric

64

The state that the bank is located in. Typically required for Chinese Bank Transfers.

bank_account_branch_address

Optional

Alphanumeric

64

The address of the bank. Typically required for Chinese Bank Transfers.

postal_code

Optional

Alphanumeric

16

ZIP postal Code

country

Mandatory

Alphanumeric

3

Account holder country code.

payment_country

Optional

Alphanumeric

3

Payment related country code – usually used for payment method specific validation (country restrictions)

state

Optional

Alphanumeric

32

State

city

Mandatory

Alphanumeric

32

City

street1

Mandatory

Alphanumeric

128

Primary Street Address

street2

Optional

Alphanumeric

128

Secondary Street Address

social_security_number

Optional

Alphanumeric

14

The Social Security number of the Account Holder.

payment_method_url

Optional

Alphanumeric

 

URL of payment method provider that user should be redirected to so payment can be finished. (not needed and ignored in request.)

attempt_three_d

Optional

TRUE/FALSE

 

Indicates that the Transaction Request should proceed with the 3D Secure workflow if the Card Holder is enrolled. Otherwise, the transaction proceeds without 3D Secure. This field is used in conjunction with Hosted Payment Page.

psp_name

Optional

Alphanumeric

256

The assigned skin name for a merchant’s customized HPP skin. This will display the merchant’s skin instead of the default skin.

psp_id

Optional

Alphanumeric

36

Not needed in request. EE internal Payment Service Provider ID.

file_name

Optional

Alphanumeric

255

Batch payment…

record_number

Optional

Numeric

11

Batch payment…

consumer_id

Optional

Alphanumeric

50

The Identifier of the Consumer.

consumer_email

Optional

Alphanumeric

64

Consumer email address.

risk_reference_id

Optional

Alphanumeric

24

 

api_id

Optional

Alphanumeric

36

Reserved for future use.

group_transaction_id

Optional

Alphanumeric

36

Common ID for all referenced transactions. It is usually transaction ID of the first transaction in chain.

notifications_format

Optional

Alphanumeric

256

Content type of the IPN (application/xml, application/json, application/x-www-form-urlencoded).

date_of_birth

Optional

YYYY-MM-DD

 

Account holder birth date.

creditor_id

Optional

Alphanumeric

35

The Creditor Id for the Merchant Account SEPA.

gender

Optional

Alphanumeric

1

Enumeration – m or f

shipping_country

Mandatory

Alphanumeric

3

The Country ID portion of the address of the Shipping Address.

shipping_state

Optional

Alphanumeric

32

The state or province portion of the address of the Shipping Address.

shipping_city

Mandatory

Alphanumeric

32

The city of the address of the Shipping Address.

shipping_postal_code

Optional

Alphanumeric

16

The postal code or ZIP of the address of the Shipping Address.

shipping_street1

Mandatory

Alphanumeric

128

The first line of the street address of the Shipping Address.

shipping_street2

Optional

Alphanumeric

128

The second line of the street address of the Shipping Address.

shipping_first_name

Mandatory

Alphanumeric

32

The first name of the Shipping Address.

shipping_last_name

Mandatory

Alphanumeric

32

The last name of the Shipping Address.

shipping_block_no

Optional

Alphanumeric

 

Additional shipping information (paylah).

shipping_level

Optional

Alphanumeric

 

Additional shipping information (paylah).

shipping_unit

Optional

Alphanumeric

 

Additional shipping information (paylah).

shipping_phone

Optional

Alphanumeric

32

The phone number of the Shipping Address.

pares

Optional

Alphanumeric

 

Digitally signed, base64-encoded authentication response message received from the issuer (3D Secure transaction).

custom_css_url

Optional

Alphanumeric

2000

URL specified by merchant pointing to the CSS resource customizing HPP/EPP.

item_name_1

O/Mandatory

Alphanumeric

256

Order item name.

item_id_1

Optional

Alphanumeric

256

Order item article identifier.

item_amount_1

O/Mandatory

Numeric

18,6

Order item amount.

item_quantity_1

O/Mandatory

Numeric

5

Order item quantity.

item_description_1

Optional

Alphanumeric

1024

Order item description.

otp

Optional

Alphanumeric

 

One time password (icashcard).

wallet_account_id

Mandatory

Alphanumeric

128

The unique identifier of the Account Holder’s Wallet Account.

browser_ip_address

Optional

Alphanumeric

32

IP address of consumer obtained by payment page in time of payment.

browser_hostname

Optional

Alphanumeric

255

Consumer’s web browser obtained by payment page in time of payment.

browser_version

Optional

Alphanumeric

255

Version number of consumer’s web browser obtained by payment page in time of payment.

browser_os

Optional

Alphanumeric

255

Consumer’s operating system obtained by payment page in time of payment.

browser_screen_resolution

Optional

Alphanumeric

32

Consumer’s screen resolution obtained by payment page in time of payment.

browser_referrer

Optional

Alphanumeric

4096

URL referring to previous page consumer visited before payment page.

liability_shift_indicator

Optional

Alphanumeric

1

Indicating liability shift in case of 3D Secure transactions. Possible values:

Y - Liability Shift transferred to issuer
N - No Liability Shift
U - LI information unavailable

consumer_date_of_birth

Optional

Alphanumeric

 

Consumer date of birth.

consumer_social_security_number

Optional

Alphanumeric

14

Social security number of the consumer.

consumer_gender

Optional

Alphanumeric

1

Gender of consumer.

order_item_amount

Mandatory

Numeric

18,6

Order item(s) price(s) per unit.

order_item_quantity

Mandatory

Numeric

5

Total count(s) of the item(s) in the order.

order_item_article_number

Optional

Alphanumeric

256

Item EAN(s) or other article(s) identifier(s).

order_item_name

Mandatory

Alphanumeric

256

Name(s) of the item(s) in the basket.

order_item_amount_currency

Mandatory

Alphanumeric

3

Currency(ies) of the order item amount(s).

order_item_tax_rate

Optional

Numeric

5,2

Order item tax rate(s) in percentage already included within order item price (order_item_amount).

order_item_tax_amount

Optional

Numeric

18,6

Order item tax(es) per unit already included within the order item price (order_item_amount).

orderItems[n].name

O/Mandatory

Alphanumeric

256

Order item name.

orderItems[n].articleNumber

Optional

Alphanumeric

256

Order item article identifier.

orderItems[n].amount.value

O/Mandatory

Numeric

18,6

Order item price.

orderItems[n].amount.currency

O/Mandatory

Alphanumeric

3

Currency of the order item price (amount.value).

orderItems[n].taxRate

Optional

Numeric

5,2

Order item tax rate in percentage already included within order item price (amount.value).

orderItems[n].taxAmount.value

Optional

Numeric

18,6

Order item tax per unit already included within the order item price (amount.value).

orderItems[n].taxAmount.currency

Optional

Alphanumeric

3

Tax amount currency.

orderItems[n].quantity

O/Mandatory

Numeric

5

Total count of the item in the order.

airline_industry_airline_code

Optional

Alphanumeric

3

The airline code assigned by IATA.

airline_industry_airline_name

Optional

Alphanumeric

64

Name of the airline.

airline_industry_passenger_code

Optional

Alphanumeric

10

The file key of the Passenger Name Record (PNR). This information is mandatory for transactions with AirPlus UATP cards.

airline_industry_passenger_name

Optional

Alphanumeric

10

The name of the Airline Transaction passenger.

airline_industry_passenger_phone

Optional

Alphanumeric

32

The phone number of the Airline Transaction passenger.

airline_industry_passenger_email

Optional

Alphanumeric

64

The Email Address of the Airline Transaction passenger.

airline_industry_passenger_ip_address

Optional

Alphanumeric

45

The IP Address of the Airline Transaction passenger.

airline_industry_ticket_issue_date

Optional

Date

 

The date the ticket was issued.

airline_industry_ticket_number

Optional

Alphanumeric

11

The airline ticket number, including the check digit. If no airline ticket number (IATA) is used, the element field must be populated with 99999999999.

airline_industry_ticket_restricted_flag

Optional

0/1

 

Indicates that the Airline Transaction is restricted. 0 = No restriction, 1 = Restricted (non-refundable).

airline_industry_pnr_file_key

Optional

Alphanumeric

 

The Passenger Name File ID for the Airline Transaction.

airline_industry_ticket_check_digit

Optional

Numeric

 

The airline ticket check digit.

airline_industry_agent_code

Optional

Alphanumeric

 

The agency code assigned by IATA. If no IATA code is used, the element field must be populated with 99999999.

airline_industry_agent_name

Optional

Alphanumeric

 

The agency name.

airline_industry_non_taxable_net_amount

Optional

Numeric

 

This field must contain the net amount of the purchase transaction in the specified currency for which the tax is levied. Two decimal places are implied. If this field contains a value greater than zero, the indicated value must differ to the content of the transaction amount.

airline_industry_ticket_issuer_street1

Mandatory

Alphanumeric

 

The Issuer Address Street for the Airline Transaction.

airline_industry_ticket_issuer_street2

Optional

Alphanumeric

 

The Issuer Address Street 2 for the Airline Transaction.

airline_industry_ticket_issuer_city

Mandatory

Alphanumeric

32

The city of the address of the Airline Transaction issuer.

airline_industry_ticket_issuer_state

Optional

Alphanumeric

 

The state of the address of the Airline Transaction issuer.

airline_industry_ticket_issuer_country

Mandatory

Alphanumeric

3

The Issuer Address Country ID for the Airline Transaction.

airline_industry_ticket_issuer_postal_code

Optional

Alphanumeric

16

An alphanumeric numeric code used to represent the Airline Transaction issuer Postal.

airline_industry_number_of_passengers

Optional

Numeric

3

The number of passengers on the Airline Transaction.

airline_industry_reservation_code

Optional

Alphanumeric

32

The reservation code of the Airline Transaction passenger.

airline_industry_itinerary_segment_n[1-10]_carrier_code

Mandatory

Alphanumeric

3

The 2-letter airline code (e.g. LH, BA, KL) supplied by IATA for each leg of a flight.

airline_industry_itinerary_segment_n[1-10]_departure_airport_code

Mandatory

Alphanumeric

3

The departure airport code. IATA assigns the airport codes.

airline_industry_itinerary_segment_n[1-10]_departure_city_code

Mandatory

Alphanumeric

32

The departure City Code of the Itinerary Segment. IATA assigns the airport codes.

airline_industry_itinerary_segment_n[1-10]_arrival_airport_code

Mandatory

Alphanumeric

3

The arrival airport code of the Itinerary Segment. IATA assigns the airport codes.

airline_industry_itinerary_segment_n[1-10]_arrival_city_code

Mandatory

Alphanumeric

32

The arrival city code of the Itinerary Segment. IATA assigns the airport codes.

airline_industry_itinerary_segment_n[1-10]_departure_date

Mandatory

Date

 

The departure date for a given leg.

airline_industry_itinerary_segment_n[1-10]_arrival_date

Mandatory

Date

 

The arrival date of the Itinerary Segment. IATA assigns the airport codes.

airline_industry_itinerary_segment_n[1-10]_flight_number

Optional

Alphanumeric

6

The flight number of the Itinerary Segment.

airline_industry_itinerary_segment_n[1-10]_fare_class

Optional

Alphanumeric

6

Used to distinguish between First Class, Business Class and Economy Class, but also used to distinguish between different fares and booking codes within the same type of service.

airline_industry_itinerary_segment_n[1-10]_fare_basis

Optional

Alphanumeric

6

Represents a specific fare and class of service with letters, numbers, or a combination of both.

airline_industry_itinerary_segment_n[1-10]_stop_over_code

Optional

0/1

 

0 = allowed, 1 = not allowed

airline_industry_itinerary_segment_n[1-10]_tax_amount

Optional

Numeric

18,6

The amount of the Value Added Tax levied on the transaction amount in the specified currency.

cruise_industry_carrier_code

Optional

Alphanumeric

10

The airline code assigned by IATA.

cruise_agent_code

Optional

Alphanumeric

10

The agency code assigned by IATA.

cruise_industry_travel_package_type_code

Optional

Alphanumeric

10

This indicates if the package includes car rental, airline flight, both or neither. Valid entries include: C = Car rental reservation included, A = Airline flight reservation included, B = Both car rental and airline flight reservations included, N = Unknown.

cruise_industry_ticket_number

Optional

Alphanumeric

15

The ticket number, including the check digit.

cruise_passenger_name

Optional

Alphanumeric

100

The name of the passenger.

cruise_lodging_check_in_date

Optional

Date

 

The cruise departure date also known as the sail date.

cruise_lodging_check_out_date

Optional

Date

 

The cruise return date also known as the sail end date.

cruise_lodging_room_rate

Optional

Numeric

18,6

The total cost of the cruise.

cruise_number_of_nights

Optional

Numeric

3

The length of the cruise in days.

cruise_lodging_name

Optional

Alphanumeric

100

The ship name booked for the cruise.

cruise_lodging_city_name

Optional

Alphanumeric

20

The name of the city where the lodging property is located.

cruise_lodging_region_code

Optional

Alphanumeric

10

The region code where the lodging property is located.

cruise_lodging_country_code

Optional

Alphanumeric

10

The country code where the lodging property is located.

cruise_industry_itinerary_segment_n[1-10]_carrier_code

Mandatory

Alphanumeric

3

The 2-letter airline code (e.g. LH, BA, KL) supplied by IATA for each leg of a flight.

cruise_industry_itinerary_segment_n[1-10]_departure_airport_code

Mandatory

Alphanumeric

3

The departure airport code. IATA assigns the airport codes.

cruise_industry_itinerary_segment_n[1-10]_departure_city_code

Mandatory

Alphanumeric

32

The departure City Code of the Itinerary Segment. IATA assigns the airport codes.

cruise_industry_itinerary_segment_n[1-10]_arrival_airport_code

Mandatory

Alphanumeric

3

The arrival airport code of the Itinerary Segment. IATA assigns the airport codes.

cruise_industry_itinerary_segment_n[1-10]_arrival_city_code

Mandatory

Alphanumeric

32

The arrival city code of the Itinerary Segment. IATA assigns the airport codes.

cruise_industry_itinerary_segment_n[1-10]_departure_date

Mandatory

Date

 

The departure date for a given leg.

cruise_industry_itinerary_segment_n[1-10]_arrival_date

Mandatory

Date

 

The arrival date of the Itinerary Segment. IATA assigns the airport codes.

cruise_industry_itinerary_segment_n[1-10]_flight_number

Optional

Alphanumeric

6

The flight number of the Itinerary Segment.

cruise_industry_itinerary_segment_n[1-10]_fare_class

Optional

Alphanumeric

6

Used to distinguish between First Class, Business Class and Economy Class, but also used to distinguish between different fares and booking codes within the same type of service.

cruise_industry_itinerary_segment_n[1-10]_fare_basis

Optional

Alphanumeric

6

Represents a specific fare and class of service with letters, numbers, or a combination of both.

cruise_industry_itinerary_segment_n[1-10]_stop_over_code

Optional

0/1

 

0 = allowed, 1 = not allowed

cruise_industry_itinerary_segment_n[1-10]_tax_amount

Optional

Numeric

18,6

The amount of the Value Added Tax levied on the transaction amount in the specified currency.

hpp_processing_timeout

Optional

String (Cardinal Number)

8

This field uses cardinal numbers which are treated like a string. It determines the timeout of an HPP page in milliseconds when this HPP page uses popup. During an open popup, Wirecard’s Payment Gateway polls query requests. If these poll requests are not accomplished until timeout, polling stops and displays a message. Default timeout is 10 minutes (value = "600000").

Response Fields
Field Cardinality Datatype Size Description

response_signature

Mandatory

Alphanumeric

64

Refer to SHA-256 response signature.

transaction_type

Mandatory

Alphanumeric

30

A unique identifier assigned for every transaction type.

transaction_state

Mandatory

Alphanumeric

12

The current status of a transaction. Typically, a transaction will start from a submitted state, to an in-progress, and then finish in either the success or failed state.

transaction_id

Mandatory

Alphanumeric

36

A unique identifier assigned for every transaction.

request_id

Mandatory

Alphanumeric

64

The unique string that the merchant sends with every transaction in order to uniquely identify it. The merchant system can subsequently request the status or existence of a transaction using this identifier.

requested_amount

Mandatory

Numeric

18,2

The only amount that accompanies the transaction when it is created and/or requested. In the case of a sale or refund, this is what the merchant requests. In the case of a chargeback, this is the amount that is being contested.

merchant_account_id

Mandatory

Alphanumeric

36

A unique identifier assigned for every Merchant Account.

completion_time_stamp

Mandatory

yyyyMMddHHmmss

14

The UTC time-stamp that represents the response.

status_code_n

Mandatory

Alphanumeric

12

The status of a transaction. This is primarily used in conjunction with the transaction state to determine the exact details of the status of the transaction.

status_description_n

Mandatory

Alphanumeric

256

Text used to describe the transaction status.

status_severity_n

Mandatory

Alphanumeric

20

The severity of the transaction, can be information, warning, error.

provider_transaction_id_n

Optional

Alphanumeric

36

The unique identifier for a provider transaction, typically generated by the provider.

provider_transaction_reference_id

Optional

Alphanumeric

36

Provider’s reference ID. This may be non-unique.

authorization_code

Mandatory

Alphanumeric

36

An alphanumeric numeric code used to represent the provider authorization.

token_id

Optional   - Or Card Number

Alphanumeric

36

A  unique identifier assigned for every card token. This is a surrogate value for the primary account number.

masked_account_number

Optional

Alphanumeric

36

A  code used to represent the card masked account.

ip_address

Optional

Alphanumeric

15

The IP address of the cardholder as recorded by the entity receiving the transaction attempt from the cardholder.

Payment Page Security

As payment information is exchanged between the merchant’s system, the consumer’s browser, and Wirecard Payment Gateway, it is important that the data exchange safeguards against man-in-the-middle attacks.

The Hosted Payment Page (HPP), Embedded Payment Page (EPP), and Seamless integration use a digital SHA-256 signature for all message exchanges. This digital signature is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature lets a recipient know that the message was created by a known sender, and that it was not altered, while transmitting.

There are two types of signatures

  • Request Signature

  • Response Signature

Secret Key Exchange

To ensure the authenticity of the request and response messages, it is required that a Secret Key is shared with the merchant.

The Secret Key is used in generation of the request_signature and response_signature fields.

It is important that the Secret Key is never shared with anyone and is protected within the Merchant Website (only used in server side code for generating the request signature or validating the response signature).

Secret Key Exchange Workflow

The Secret Key will be communicated at the time of Merchant Account setup. Please contact your support representative if you did not receive a Secret Key or require Secret Key regeneration.

Digital Signature

Hosted Payment Page uses a digital SHA-256 signature for all message exchanges. The signature is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, and that it was not altered in transit.

Signatures

Please contact Wirecard´s Merchant Support to obtain the secret key used to sign Payment Page requests.

Request Signature

When the merchant creates the JavaScript data, the following values

  • are to be concatenated,

  • leading and trailing spaces removed, and

  • SHA-256 signature follows the combined string.

Please note that the order of the fields is important. Also note, the same values used in the request signature must be placed into the client side data (with the exception of the secret key).
  1. request_time_stamp

  2. request_id

  3. merchant_account_id

  4. transaction_type

  5. requested_amount

  6. requested_amount_currency

  7. redirect_url (optional)

  8. custom_css_url (optional)

  9. ip_address (optional)

  10. [secretkey]

If an optional field is used in the request data, it is mandatory in the request signature.

The SHA-256 hash value is then presented on the merchants client side form as request_signature field.

An example of request signature generation is as follows:

request_time_stamp              = '20190430123012'
request_id                      = 'order-12345'
merchant_account_id             = 'b19fb056-d8da-449b-ac85-cfbfd0558914'
transaction_type                = 'purchase'
requested_amount                = '1.01'
requested_amount_currency       = 'USD'
redirect_url                    = 'https://test.com'
custom_css_url                  = 'https://test.com/custom.css'
ip_address                      = '127.0.0.1'
hyperlink_expiration_time_stamp = '2020-04-07T13:20:00+02:00'
secret_key                      = 'efabf47b-e43b-4785-873f-1c5bc65b7cd2'


Pre SHA-256 string
20120430123012order-12345b19fb056-d8da-449b-ac85-cfbfd0558914purchase1.01USDhttps://test.comhttps://test.com/custom.css127.0.0.1efabf47b-e43b-4785-873f-1c5bc65b7cd2
Response Signature

Within the response message the following values

  • are concatenated,

  • leading and trailing space removed, and

  • SHA-256 signature follows the combined string.

Response signature calculation is very similar to request signature calculation. String of the concatenated fields is hashed with SHA256 so the algorithm is very same as already explained above. There are just different fields in different order concatenated. Use the following fields in this exact order only when creating the "string to hash":

  1. merchant_account_id

  2. transaction_id

  3. request_id

  4. transaction_type

  5. transaction_state

  6. completion_time_stamp

  7. token_id

  8. masked_account_number

  9. ip_address

  10. authorization_code

  11. [secretkey]

If the particular field is missing in response then the empty string should be used instead of this field.

Signature Generation Code Samples

Below you find code samples in various programming languages that you can use in your shop system. These samples take care of generating digital request signature.

PHP Example (PHP 5 >= 5.1.2, PHP 7, PECL hash >= 1.1)
$request_signature = hash('sha256', trim($request_time_stamp . $request_id . $merchant_account_id . $transaction_type . $requested_amount . $request_amount_currency . $redirect_url . $ip_address . $secret_key));
C# / ASP.NET Example
public static string GetSHA256(string text) {
       byte[] hashValue;
       byte[] message = Encoding.UTF8.GetBytes(text);

       SHA256Managed hashString = new SHA256Managed();
       string hex = "";

       hashValue = hashString.ComputeHash(message);
       foreach( byte x in hashValue)
       {
             hex += String.Format("{0:x2}", x);
       }
       return hex.Trim();
}
Java Example
private static String tosha256(String... fields) {
    StringBuffer sb = null;
    try {
        MessageDigest md = MessageDigest.getInstance("SHA-256");
        sb = new StringBuffer();
        for (String field : fields) {
            sb.append(field.trim());
        }
        md.update(sb.toString().getBytes("utf-8"));
        byte[] mdbytes = md.digest();
        return DatatypeConverter.printHexBinary(mdbytes);
    } catch (NoSuchAlgorithmException e) {
        sb = null;
    } catch (UnsupportedEncodingException e) {
        sb = null;
    }
    return sb == null ? null : sb.toString();
}
GROOVY Example
import java.security.MessageDigest;
...

def messageDigest = MessageDigest.getInstance("SHA256");
def secret_key = 'XXXXXXXXXXXXXXXXXXXXXX';

def stringToHash = time_stamp + request_id + merchant_account_id + transaction_type + requested_amount + requested_amount_currency + redirect_url + ip_address + secret_key;

messageDigest.update( stringToHash.trim().getBytes() );
def shaHex = new BigInteger(1, messageDigest.digest()).toString(16);
Signature v2

The signature consists of two parts:

  1. The signature’s payload - the actual information you are sending in the message,

  2. and its calculated value - the generated numeric cipher used for authentication

Both are Base64 URL safe encoded and separated by a period.

Sample Signature v2
SFMyNTYKcmVxdWVzdF90aW1lX3N0YW1wPTIwMTYtMDctMjdUMTQ6MzM6NDkrMDI6MDAKbWVyY2hhbnRfYWNjb3VudF9pZD05ODczYWM2NS02ZjI4LTRiNzUtYWU1NS05ZDU0OWNmNTcwZTM.2VTPD7hAiCW-NdDaUqN7pjwizuwHvirVEs1HdGU-iz0
Format

For mobile:

The signature is included in Authorization header of HTTP request that contains the authorization scheme and body.

Sample Header
Authorization: SFMyNTYKcmVxdWVzdF90aW1lX3N0YW1wPTIwMTYtMDctMjdUMTQ6MzM6NDkrMDI6MDAKbWVyY2hhbnRfYWNjb3VudF9pZD05ODczYWM2NS02ZjI4LTRiNzUtYWU1NS05ZDU0OWNmNTcwZTM.2VTPD7hAiCW-NdDaUqN7pjwizuwHvirVEs1HdGU-iz0

For seamless and HPP/EPP: 

The value is then presented on the merchant’s client side form as request_signature_v2 field.

Field Value Example
WAUTH SFMyNTYKcmVxdWVzdF90aW1lX3N0YW1wPTIwMTYtMDctMjdUMTQ6MzM6NDkrMDI6MDAKbWVyY2hhbnRfYWNjb3VudF9pZD05ODczYWM2NS02ZjI4LTRiNzUtYWU1NS05ZDU0OWNmNTcwZTM.2VTPD7hAiCW-NdDaUqN7pjwizuwHvirVEs1HdGU-iz0

Currently the scheme is WAUTH and the body consists from signature payload and calculated value, both Base64 URL safe encoded and separated with a period.

In the future another schema with different body formats could be added.
Signature v2 Payload

The signature’s payload contains:

  1. The name of the algorithm which is used to calculate the signature,

  2. and other fields, in name-value pair format, separated by a new line \n

Payload Example
algorithmName\n
field1=value1\n
field2=value2\n
…
fieldX=valueX
Supported Fields for the Payload
Field Cardinality Details

request_time_stamp

M

 e.g. 2016-07-27T14:33:49+02:00 (ISO)

merchant_account_id

M

e.g. 9873ac65-6f28-4b75-ae55-9d549cf570e3

request_id

M

e.g. 0c06f2b9-f47e-41d1-9eec-9c9352f0247f

transaction_type

M

 e.g. debit

requested_amount

M

e.g. 1.01 (ISO)

requested_amount_currency

M

e.g. EUR (ISO)

redirect_url

O

e.g. https://www.shop.com/redirect

custom_css_url

O

e.g. https://www.shop.com/custom.css

ip_address

O

e.g. 127.0.0.1

Fields with cardinality M in the table above are required for the calculation of the signature, so you always include them in the signature’s payload. The use of the other fields depends on your needs. The algorithm’s name has to be put in the payload first, but all of the other fields can be specified in any order.

Some of the information you enter in the fields has been standardized by ISO (International Organization for Standardization) to avoid confusion. We recommend you follow these standards (the examples provided here do).

You can learn more about the standards for date and time and currencies on the provided links.

The currently supported algorithm is the HS256 hash-based message authentication code with SHA-256 cryptographic hash function.

Sample Signature Payload (before encoding)
HS256
request_time_stamp=2019-03-23T09:14:51Z
merchant_account_id=33f6d473-3036-4ca5-acb5-8c64dac862d1
request_id=A7B51ED4-9EB0-48D1-82AA-2145A7792C6B
transaction_type=authorization
requested_amount=1.01
requested_amount_currency=EUR
redirect_url=https://www.shop.com/redirect
custom_css_url=https://www.shop.com/custom.css
ip_address=127.0.0.1
Sample Signature Payload + Generated Value (after Base64 encoding)
SFMyNTYKcmVxdWVzdF90aW1lX3N0YW1wPTIwMTctMDMtMjNUMDk6MTQ6NTFaCm1lcmNoYW50X2FjY291bnRfaWQ9MzNmNmQ0NzMtMzAzNi00Y2E1LWFjYjUtOGM2NGRhYzg2MmQxCnJlcXVlc3RfaWQ9QTdCNTFFRDQtOUVCMC00OEQxLTgyQUEtMjE0NUE3NzkyQzZCCnRyYW5zYWN0aW9uX3R
5cGU9YXV0aG9yaXphdGlvbgpyZXF1ZXN0ZWRfYW1vdW50PTEuMDEKcmVxdWVzdGVkX2Ftb3VudF9jdXJyZW5jeT1FVVI=.HZKtk+UfuA9IV6082jR+OLuZUZnlpSKW6lNFgZX2BEk=
Calculating the Signature

You calculate the signature’s value from the payload, using the Secret key and the specified algorithm in algorithmName.

Java Example: Signature v2 Calculation
public String generateSignatureV2() {
   Map<String, String> map = new HashMap<>();
   map.put("request_time_stamp", "2019-07-26T11:02:32+02:00"); // yyyy-MM-dd'T'HH:mm:ssXXX
   map.put("request_id", "ec1c6f40-9811-4c31-936a-5e4ca9ba9003");
   map.put("merchant_account_id", "61e8c484-dbb3-4b69-ad8f-706f13ca141b");
   map.put("transaction_type", "purchase");
   map.put("requested_amount", "1.05");
   map.put("requested_amount_currency", "EUR");

   return toHmacSha256(map, "e94f5232-1171-4f03-a59e-67e3f2e7d374");
 }

 private String toHmacSha256(Map<String, String> fields, String secret) {
   Charset charset = Charset.forName("UTF-8");

   StringBuilder builder = new StringBuilder("HS256\n");
   for (Map.Entry<String, String> field : fields.entrySet()) {
     builder.append(field.getKey());
     builder.append("=");
     builder.append(field.getValue());
     builder.append("\n");
   }
   byte[] data = builder.toString().getBytes(charset);
   byte[] key = secret.getBytes(charset);
   byte[] sign = sign(key, data);
   return new StringBuilder()
        .append(DatatypeConverter.printBase64Binary(data))
        .append(".")
        .append(DatatypeConverter.printBase64Binary(sign))
        .toString();
 }

 public byte[] sign(byte[] key, byte[] data) {
   try {
     Mac mac = Mac.getInstance("HmacSHA256");
     mac.init(new SecretKeySpec(key, "HmacSHA256"));
     byte[] signature = mac.doFinal(data);
     return signature;
   } catch (NoSuchAlgorithmException | InvalidKeyException e) {
      return null;
    }
 }
PHP Example: Signature v2 Calculation
<?php

function generateSignatureV2()
{
  $data = [];
  $data["custom_css_url"] = "";
  $data["request_time_stamp"] = "2019-07-26T11:02:32+02:00";
  $data["merchant_account_id"] = "61e8c484-dbb3-4b69-ad8f-706f13ca141b";
  $data["requested_amount_currency"] = "EUR";
  $data["ip_address"] = "127.0.0.1";
  $data["transaction_type"] = "purchase";
  $data["request_id"] = "ec1c6f40-9811-4c31-936a-5e4ca9ba9003";
  $data["requested_amount"] = "1.05";
  $data["redirect_url"] = "";
  return toSha256($data, "e94f5232-1171-4f03-a59e-67e3f2e7d374");
}

function toSha256($fields, $secret): string
{
 array_walk($fields, function (&$item, $key) {
  $item = "$key=$item";
 });
 $data = "HS256\n".implode("\n", $fields)."\n";
 return base64_encode($data) . '.' . base64_encode(sign($data, $secret));
}

function sign($data, $secret)
{
  $sig = hash_hmac('sha256', $data, $secret, true);
  return $sig;
}
echo generateSignatureV2();
C# .NET Example: Signature v2 Calculation
using System;
using System.Collections.Generic;
using System.Security.Cryptography;
using System.Text;
namespace SignatureGenerator
{
  class MainClass
  {
    public static Queue<Tuple<string, string>> CreatePaymentValues()
    {
      Queue<Tuple<string, string>> values = new Queue<Tuple<string, string>>();
      values.Enqueue(Tuple.Create("request_time_stamp", "2019-03-23T09:14:51Z"));
      values.Enqueue(Tuple.Create("merchant_account_id", "33f6d473-3036-4ca5-acb5-8c64dac862d1"));
      values.Enqueue(Tuple.Create("request_id", "A7B51ED4-9EB0-48D1-82AA-2145A7792C6B"));
      values.Enqueue(Tuple.Create("transaction_type", "authorization"));
      values.Enqueue(Tuple.Create("requested_amount", "1.01"));
      values.Enqueue(Tuple.Create("requested_amount_currency", "EUR"));
      return values;
    }
    public static byte[] BuildPayload(Queue<Tuple<string, string>> nameValues)
    {
      StringBuilder sb = new StringBuilder("HS256");
      foreach (Tuple<string, string> nameValue in nameValues)
      {
        sb.Append(Environment.NewLine);
        sb.Append(nameValue.Item1);
        sb.Append("=");
        sb.Append(nameValue.Item2);
      }
      string payload = sb.ToString();
      return Encoding.ASCII.GetBytes(payload);
    }
    public static byte[] SignPayload(byte[] body, byte[] key)
    {
      using (HMACSHA256 hmac = new HMACSHA256(key))
      {
        byte[] hash = hmac.ComputeHash(body);
        return hash;
      }
    }
    public static string FormatSignature(byte[] body, byte[] hash)
    {
      StringBuilder sb = new StringBuilder();
      sb.Append(Convert.ToBase64String(body));
      sb.Append(".");
      sb.Append(Convert.ToBase64String(hash));
      string signature = sb.ToString();
      return signature;
    }
#pragma warning disable RECS0154 // Parameter is never used
    public static void Main(string[] args)
#pragma warning restore RECS0154 // Parameter is never used
    {
      byte[] secretKey = Encoding.ASCII.GetBytes("9e0130f6-2e1e-4185-b0d5-dc69079c75cc");
      byte[] payload = BuildPayload(CreatePaymentValues());
      byte[] hash = SignPayload(payload, secretKey);
      string signature = FormatSignature(payload, hash);
      Console.WriteLine("WAUTH {0}", signature);
    }
  }
}

The signature’s expiration period is 30 minutes by default (configurable). The expiration check uses the timestamp from the payload for reference.

Verifying the Response Signature

To check the signature you send in your payment request, Wirecard Payment Gateway calculates it in the same fashion and compares it to the value in the request. Then it calculates a new signature for the payment response — using fields from that response in the payload this time — for you to be able to verify that it was not interfered with by a 3rd party.

As a result, verifying this response signature on your side follows the same process like when you calculate it for your payment request, but the signature’s payload fields come from the response you receive. After you calculate the value, compare it to the one found in the response (in the response_signature_v2 field).

To recap, in order to verify the response signature you calculate it based on the payment response you receive from Wirecard Payment Gateway (following the same steps as when calculating it for a payment request , but with a different payload). Then you compare the two values. 

The response signature is found in the response_signature_v2 field.   .Sample Response

country=DE&merchant_account_resolver_category=&response_signature=65b8c66e85d344af2f88d7474e5dcb7d612a67273806c0b053ae5b19fcc165a9&city=Berlin&group_transaction_id=&provider_status_code_1=&response_signature_v2=SFMyNTYKdHJhbnNhY3Rpb25faWQ9ZGUyMDk3ZDktYjliNi00ZGUyLTg0MTAtNDZlYWZiMjdhNzRiCmNvbXBsZXRpb25fdGltZXN0YW1wPTIwMTgwMTI0MDk1NzE1Cm1hc2tlZF9hY2NvdW50X251bWJlcj00NDQ0MzMqKioqKioxMTExCnRva2VuX2lkPTQwNjIzMzIxNDg3MDExMTEKYXV0aG9yaXphdGlvbl9jb2RlPTE1MzYyMAptZXJjaGFudF9hY2NvdW50X2lkPWZmMzllNmZkLTM1ZjQtMTFlNS05ZTliLWY4MTY1NDYzMjMyOAp0cmFuc2FjdGlvbl9zdGF0ZT1zdWNjZXNzCmlwX2FkZHJlc3M9MTI3LjAuMC4xCnRyYW5zYWN0aW9uX3R5cGU9cHVyY2hhc2UKcmVxdWVzdF9pZD04YjNjMDBlMS01NmViLTM3ZTQtNDc4Yi1mZGM3ODUyZTNkYWYK.swLVerxpdEb468tFXEr3VDriima0rFG97XDHFyt7F4A%3D&requested_amount=224&completion_time_stamp=20190524095715&provider_status_description_1=&token_id=4062332148701111&authorization_code=153620&merchant_account_id=ff39e6fd-35f4-11e5-9e9b-f81654632328&provider_transaction_reference_id=&street1=Mullerstrasse+137&state=Berlin&first_name=John&email=john%40doe.com&transaction_id=de2097d9-b9b6-4de2-8410-46eafb27a74b&provider_transaction_id_1=&status_severity_1=information&last_name=Doe&ip_address=127.0.0.1&transaction_type=purchase&status_code_1=201.0000&masked_account_number=444433******1111&status_description_1=3d-acquirer%3AThe+resource+was+successfully+created.&phone=%2B421123456789&transaction_state=success&requested_amount_currency=EUR&postal_code=13353&request_id=8b3c00e1-56eb-37e4-478b-fdc7852e3daf
You only work with response_signature_v2. Do not confuse response_signature_v2 with response_signature. Both are sent in the response, but the response_signature field contains the legacy Signature v1 response signature.
Payload for Calculation (Based on the Sample)
HS256
transaction_id=de2097d9-b9b6-4de2-8410-46eafb27a74b
completion_timestamp=20190524095715
masked_account_number=444433******1111
token_id=4062332148701111
authorization_code=153620
merchant_account_id=ff39e6fd-35f4-11e5-9e9b-f81654632328
transaction_state=success
ip_address=127.0.0.1
transaction_type=purchase
request_id=8b3c00e1-56eb-37e4-478b-fdc7852e3daf
Calculating the Value

Again, you calculate the signature’s value from the payload, using the Secret Key (e94f5232-1171-4f03-a59e-67e3f2e7d374) and the specified algorithm (HS256).  

Java Signature v2 Verification Calculation Example
public String generateSignatureV2() {
   Map<String, String> map = new HashMap<>();
   map.put("transaction_id", "de2097d9-b9b6-4de2-8410-46eafb27a74b");
   map.put("completion_time_stamp", "20190524095715");
   map.put("masked_account_number", "444433******1111");
   map.put("token_id", "4062332148701111");
   map.put("authorization_code", "153620");
   map.put("merchant_account_id", "ff39e6fd-35f4-11e5-9e9b-f81654632328");
   map.put("transaction_state", "success");
   map.put("ip_address", "127.0.0.1");
   map.put("transaction_type", "purchase");
   map.put("request_id", "8b3c00e1-56eb-37e4-478b-fdc7852e3daf");

   return toHmacSha256(map, "e94f5232-1171-4f03-a59e-67e3f2e7d374");
 }

 private String toHmacSha256(Map<String, String> fields, String secret) {
   Charset charset = Charset.forName("UTF-8");

   StringBuilder builder = new StringBuilder("HS256\n");
   for (Map.Entry<String, String> field : fields.entrySet()) {
     builder.append(field.getKey());
     builder.append("=");
     builder.append(field.getValue());
     builder.append("\n");
   }
   byte[] data = builder.toString().getBytes(charset);
   byte[] key = secret.getBytes(charset);
   byte[] sign = sign(key, data);
   return new StringBuilder()
        .append(DatatypeConverter.printBase64Binary(data))
        .append(".")
        .append(DatatypeConverter.printBase64Binary(sign))
        .toString();
 }

 public byte[] sign(byte[] key, byte[] data) {
   try {
     Mac mac = Mac.getInstance("HmacSHA256");
     mac.init(new SecretKeySpec(key, "HmacSHA256"));
     byte[] signature = mac.doFinal(data);
     return signature;
   } catch (NoSuchAlgorithmException | InvalidKeyException e) {
      return null;
    }
 }
PHP Signature v2 Verification Calculation Example
<?php
function generateSignatureV2()
{
  $data = [];
  $data["transaction_id"] = "de2097d9-b9b6-4de2-8410-46eafb27a74b";
  $data["completion_time_stamp"] = "20190524095715";
  $data["masked_account_number"] = "444433******1111";
  $data["token_id"] = "4062332148701111";
  $data["authorization_code"] = "153620";
  $data["merchant_account_id"] = "ff39e6fd-35f4-11e5-9e9b-f81654632328";
  $data["transaction_state"] = "success";
  $data["ip_address"] = "127.0.0.1";
  $data["transaction_type"] = "purchase";
  $data["request_id"] = "8b3c00e1-56eb-37e4-478b-fdc7852e3daf";
  return toSha256($data, "e94f5232-1171-4f03-a59e-67e3f2e7d374");
}

function toSha256($fields, $secret): string
{
  array_walk($fields, function (&$item, $key) {
    $item = "$key=$item";
  });
  $data = "HS256\n".implode("\n", $fields)."\n";
  return base64_encode($data) . '.' . base64_encode(sign($data, $secret));
}

function sign($data, $secret)
{
  $sig = hash_hmac('sha256', $data, $secret, true);
  return $sig;
}

echo generateSignatureV2();
C# .NET Signature v2 Verification Calculation Example
using System;
using System.Collections.Generic;
using System.Security.Cryptography;
using System.Text;
namespace SignatureGenerator
{
  class MainClass
  {
    public static Queue<Tuple<string, string>> CreatePaymentValues()
    {
      Queue<Tuple<string, string>> values = new Queue<Tuple<string, string>>();
      values.Enqueue(Tuple.Create("transaction_id", "de2097d9-b9b6-4de2-8410-46eafb27a74b"));
      values.Enqueue(Tuple.Create("completion_time_stamp", "20190524095715"));
      values.Enqueue(Tuple.Create("masked_account_number", "444433******1111"));
      values.Enqueue(Tuple.Create("token_id", "4062332148701111"));
      values.Enqueue(Tuple.Create("authorization_code", "153620"));
      values.Enqueue(Tuple.Create("merchant_account_id", "ff39e6fd-35f4-11e5-9e9b-f81654632328"));
      values.Enqueue(Tuple.Create("transaction_state", "success"));
      values.Enqueue(Tuple.Create("ip_address", "127.0.0.1"));
      values.Enqueue(Tuple.Create("transaction_type", "purchase"));
      values.Enqueue(Tuple.Create("request_id", "8b3c00e1-56eb-37e4-478b-fdc7852e3daf"));
      return values;
    }
    public static byte[] BuildPayload(Queue<Tuple<string, string>> nameValues)
    {
      StringBuilder sb = new StringBuilder("HS256");
      foreach (Tuple<string, string> nameValue in nameValues)
      {
        sb.Append(Environment.NewLine);
        sb.Append(nameValue.Item1);
        sb.Append("=");
        sb.Append(nameValue.Item2);
      }
      string payload = sb.ToString();
      return Encoding.ASCII.GetBytes(payload);
    }
    public static byte[] SignPayload(byte[] body, byte[] key)
    {
      using (HMACSHA256 hmac = new HMACSHA256(key))
      {
        byte[] hash = hmac.ComputeHash(body);
        return hash;
      }
    }
    public static string FormatSignature(byte[] body, byte[] hash)
    {
      StringBuilder sb = new StringBuilder();
      sb.Append(Convert.ToBase64String(body));
      sb.Append(".");
      sb.Append(Convert.ToBase64String(hash));
      string signature = sb.ToString();
      return signature;
    }
#pragma warning disable RECS0154 // Parameter is never used
    public static void Main(string[] args)
#pragma warning restore RECS0154 // Parameter is never used
    {
      byte[] secretKey = Encoding.ASCII.GetBytes("9e0130f6-2e1e-4185-b0d5-dc69079c75cc");
      byte[] payload = BuildPayload(CreatePaymentValues());
      byte[] hash = SignPayload(payload, secretKey);
      string signature = FormatSignature(payload, hash);
      Console.WriteLine("WAUTH {0}", signature);
    }
  }
}

Payment Selection

Wirecard Payment Page v1 displays the payment method selection screen if the field payment_method is left out or left empty and more than one payment method is configured for the merchant in the Wirecard Payment Gateway. It may be used to display all available payment methods or the list of displayed payment methods may be narrowed down by specifying the value of field transaction_type to authorization or debit.

Automatic Payment Method Selection

The payment page supports automatic selection of payment methods in order to bypass the payment method selection screen. Simply set payment_method in the initial payment request to force the selection of a specific payment method. You can also specify several payment methods in the request to offer methods to select.

Prepopulation of Consumer Information

The payment page supports prepopulation of consumer information to reduce or eliminate consumer data entry. Consumer information such as name, order and address information can be sent within the initial payment request. The payment page will use these values as default, which can be manually overridden.

Credit Card Transactions

When processing credit card transactions via the payment page, there is an option to avoid the rendering of the payment page. Subsequent processing redirects such as 3D Secure are automatically handled. To enable SilentPay processing, the merchant must pass the following fields within the initial payment request:

  • account_number

  • holder_last_name

  • card_type

  • card_security_code

  • expiration_year

  • expiration_month

3D Secure

3D Secure payment can be processed via all the three Payment Page integrations: HPP, EPP or Seamless. The main benefit is a simple credit card payment request. The payment page automatically performs all necessary steps to check 3D enrollment of the card, redirects to the cardholder’s bank and processes a response.

3D Secure 2 is now also available and set to become the prime authentication method for online card payments, thanks to a number of updates that improve not only the security, but also the consumer experience of 3D Secure 1 (3DS).

The workflow remains the same but 3D Secure 2 requires additional fields.

Preconditions

In order to process card payments with a 3D Secure verification, following two preconditions must be met:

  1. The initial payment request needs to contain attempt_three_d attribute set to true.

    Field Required Datatype Value Description

    attempt_three_d

    Optional

    Boolean

    true/false

    Indicates that the Transaction Request should proceed with the 3D Secure workflow if the [Card Holder] is enrolled. Otherwise, the transaction proceeds without 3D Secure.

    Sample Request
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
    <html>
      <head>
        <title>
          Demo shop
        </title>
        <script src="https://api-test.wirecard.com/engine/hpp/paymentPageLoader.js" type="text/javascript"></script>
      </head>
      <body>
        <form>
          <input id="wirecard_pay_btn" type="button" onclick="pay()" value="Pay Now">
           <script type="text/javascript">
            function pay() {
            var requestedData = {
                merchant_account_id: "61e8c484-dbb3-4b69-ad8f-706f13ca141b",
                request_id: "c68b9039-968d-1c6b-d9f6-27e9ab2bcb3e",
                request_time_stamp: “20150226084718”,
                payment_method: "creditcard",
                transaction_type: "purchase",
                requested_amount: "2.56",
                requested_amount_currency: "EUR",
                locale: "en",
                attempt_three_d: "true",
                request_signature: "kg44730486d159df0bc2e8dea22bd175395636a37b0da0ef785"
             }
            WirecardPaymentPage.hostedPay(requestedData);
            }
          </script>
        </form>
      </body>
    </html>
  2. The merchant account needs to have 3D Secure transactions enabled (contact Merchant Support for queries).


3D Secure 2 - Additional Request Fields

To 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.

Most of these fields are optional but we recommend the implementation of optional fields, as this creates a smoother user experience and ensures a higher level of security.

Need more information on 3D Secure 2? Head to our general introduction to 3D Secure 2.

Field Cardinality Datatype Size Description

authentication_method

Optional

String

2  

Type of consumer login in the merchant’s shop.
Possible values: 01, 02, 03, 04, 05, 06
01 = Guest checkout (i.e. the consumer is not logged in).
02 = Login to the consumer’s account in merchant’s shop with shop-own authentication credentials.
03 = Login with Federated ID.
04 = Login with card issuer credentials.
05 = Login with third-party authentication.
06 = Login with FIDO authenticator.
This field is conditional. If you do not include it in the request, the likelihood that the transaction will be challenged increases.

authentication_timestamp

Conditional

YYYY-MM-DDThh:mm:ss

19  

Date and time (UTC) of the consumer login in the merchant’s shop. Accepted format: YYYY-MM-DDThh:mm:ss. For guest checkout, the datetime is now.
This field is conditional. If you do not include it in the request, the likelihood that the transaction will be challenged increases.

challenge_indicator

Optional

String

2  

Indicates whether a challenge is requested for this transaction.
Possible values: 01, 02, 03, 04
01 = No preference.
02 = No challenge requested.
03 = Challenge requested: Merchant Preference.
04 = Challenge requested: Mandate. Must be sent in a first transaction that stores a token (e.g. for one-click checkout).

account_creation_date

Optional

Date

10

Registration date of the consumer’s account in the merchant’s shop. Accepted format: YYYY-MM-DD. For guest checkout, do not send this field.

account_update_date

Optional

Date

10  

Date that the consumer last made changes to their account in the merchant’s shop. For example, changes to billing and shipping address, new payment account, new email address. Accepted format: YYYY-MM-DD. For guest checkout, do not send this field.

account_password_change_date

Optional

Date

10 

Date that the consumer last changed/reset their password in the merchant’s shop. Accepted format: YYYY-MM-DD. For guest checkout, do not send this field.

shipping_address_first_use

Optional

Date

10  

Date that the consumer first used this shipping address in the merchant’s shop. Accepted format: YYYY-MM-DD. For guest checkout, do not send this field.

transactions_last_day

Optional

Numeric

9  

Number of transactions (successful, failed, and canceled) that the consumer has attempted in the past 24 hours. Does not include merchant-initiated transactions.

transactions_last_year

Optional

Numeric

9  

Number of transactions (successful, failed, and canceled) that the consumer has attempted within the past year. Does not include merchant-initiated transactions.

card_transactions_last_day

Optional

Numeric

9  

Number of cards the consumer has attempted to add to their account in the merchant’s shop for card-on-file payments (one-click checkout) in the past 24 hours.

purchases_last_six_months

Optional

Numeric

9  

Number of successful orders by the consumer in the merchant’s shop within the past six months.

suspicious_activity

Optional

Boolean

 

Indicates if the merchant knows of suspicious activities by the consumer (e.g. previous fraud).

card_creation_date

Optional

Date

10 

Date that the consumer’s card was added to their account in the merchant’s shop for card-on-file payments (one-click checkout). Accepted format: YYYY-MM-DD.
For all other types of checkout (e.g. guest checkout, regular checkout, the first transaction with one-click checkout), the datetime is now.

merchant_crm_id

Optional

String

64

Consumer identifier in the merchant’s shop. Requests that contain payment information from the same consumer in the same shop must contain the same string.

city

Conditional

String

50

City of the consumer’s billing address.
This field is conditional. If you do not include it in the request, the likelihood that the transaction will be challenged increases.

country

Conditional

String

2

Country of the consumer’s billing address.
This field is conditional. If you do not include it in the request, the likelihood that the transaction will be challenged increases.

street1

Conditional

String

50

Line 1 of the street address of the consumer’s billing address.
This field is conditional. If you do not include it in the request, the likelihood that the transaction will be challenged increases.

street2

Conditional

String

50

Line 2 of the street address of the consumer’s billing address.
This field is conditional. If you do not include it in the request, the likelihood that the transaction will be challenged increases.

street3

Conditional

String

50

Line 3 of the street address of the consumer’s billing address.
This field is conditional. If you do not include it in the request, the likelihood that the transaction will be challenged increases.

postal_code

Conditional

String

16

ZIP/postal code of the consumer’s billing address.
This field is conditional. If you do not include it in the request, the likelihood that the transaction will be challenged increases.

state

Conditional

String

3

State/province of the consumer’s billing address. Accepted format: numeric ISO 3166-2 standard.
This field is conditional. If you do not include it in the request, the likelihood that the transaction will be challenged increases.

email

Conditional

String

256

The consumer’s email address as given in the merchant’s shop.
This field is conditional. If you do not include it in the request, the likelihood that the transaction will be challenged increases.

home_phone

Conditional

String

18

Home phone number provided by the consumer.
This field is required if available.

mobile_phone

Conditional

String

18

Mobile phone number provided by the consumer.
This field is required if available.

work_phone

Conditional

String

18

Work phone number provided by the consumer.
This field is required if available.

last_name

Mandatory

String

50

The last name provided by the consumer as part of the credit card details.

first_name

Mandatory

String

50

The first name provided by the consumer as part of the credit card details.

shipping_shipping_method

Optional

String

2  

The shipping method chosen by the consumer. Merchants must use the shipping indicator value that applies most accurately to the shipping method.
Accepted values are:

  • home_delivery: Ship to consumer’s billing address.

  • verified_address_delivery: Ship to another address known to and verified by the merchant.

  • other_address_delivery: Ship to an address that differs from the consumer’s billing address.

  • store_pick_up: "Ship to Store" / Pick-up at local store (store address in shipping address fields).

  • digital_goods: Digital goods (includes online services, electronic gift cards, and redemption codes).

  • digital_tickets: Travel and event tickets, not shipped.

  • other_verified: Other (e.g. gaming, digital services, e-media subscriptions)

shipping_city

Conditional

String

50

City of the consumer’s shipping address. Must be sent even if billing city is identical.
This field does not apply to digital goods.

shipping_country

Conditional

String

2

Country of the consumer’s shipping address. Must be sent even if billing country is identical.
This field does not apply to digital goods.

shipping_street1

Conditional

String

50

Line 1 of the street address of the consumer’s shipping address. Must be sent even if billing address is identical.
This field does not apply to digital goods.

shipping_street2

Conditional

String

50

Line 2 of the street address of the consumer’s shipping address. Must be sent even if billing address is identical.
This field does not apply to digital goods.

shipping_street3

Conditional

String

50

Line 3 of the street address of the consumer’s shipping address. Must be sent even if billing address is identical.
This field does not apply to digital goods.

shipping_postal_code

Conditional

String

16

ZIP/postal code of the consumer’s shipping address. Must be sent even if billing address is identical.
This field does not apply to digital goods.

shipping_state

Conditional

String

3

State/province of the consumer’s shipping address. Accepted format: numeric ISO 3166-2 standard. Must be sent even if billing address is identical.
This field does not apply to digital goods.

risk_info_delivery_timeframe

Optional

String

2  

The approximate delivery time.
Accepted values are: 01, 02, 03, 04
01 = Electronic delivery
02 = Same-day delivery
03 = Overnight delivery
04 = Two-day or more delivery

risk_info_delivery_mail

Optional

String

254

The consumer’s email address used for electronic delivery of digital goods.

risk_info_reorder_items

Optional

String

2  

The consumer has previously ordered the same item. Accepted values are: 01, 02
01 = First-time order
02 = Reorder

risk_info_availability

Optional

String

2  

The consumer is placing an order for merchandise that is not yet available and will be released in the future. Accepted values are: 01, 02
01 = Currently available
02 = Future availability

risk_info_preorder_date

Optional

Date

10  

Expected shipping date for pre-ordered goods. Accepted format: YYYY-MM-DD.

risk_info_gift_amount

Optional

Numeric

 

For the purchase of prepaid and gift cards. The total amount of prepaid/gift card in major units (no decimal places allowed).

risk_info_gift_amount_currency

Optional

String

3

The currency code for prepaid and gift cards. Accepted format: ISO 4217.

risk_info_gift_card_count

Optional

Numeric

The total number of prepaid and gift cards that are being purchased.

recurring_expire_date

Optional

Date

10

For recurring payments only. Date after which no further recurring payments using this card are allowed. Accepted format: YYYY-MM-DD.

recurring_frequency

Optional

Numeric

4

For recurring payments only. The minimum number of days between individual payments.

iso_transaction_type

Optional

String

2  

Identifies the transaction type. The values are derived from ISO 8583. Accepted values are: 01, 03, 10, 11, 28
01 = Goods/ Service Purchase
03 = Check Acceptance
10 = Account Funding
11 = Quasi-Cash Transaction
28 = Prepaid Activation and Load

three_d_version

Optional

String

5

Identifies the version of 3D Secure authentication used for the transaction. Accepted values are: 1.0, or 2.1

The 3D Secure Workflow of the Payment Page

The workflow of 3D secure behaves almost identical for HPP, EPP and Seamless.

Two differences can be observed. One after a successful check of a card enrollment and another one after a successful authentication check.

See workflow graphic for details.

3D Secure Workflow
Figure 8. Workflow Graphic
Submit Form for Redirect
<form action="{acs_URL}" method="post" enctype="application/x-www-form-urlencoded" id="acsform">
    <input type="hidden" name="PaReq" value="{pareq}"/>
    <input type="hidden" name="TermUrl" value="https://api-test.wirecard.com/engine/rest/hpp/acs/{transaction_id}/"/>
    <input type="hidden" name="MD" value="merchant_account_id={MAID}&transaction_type=purchase&nonce3d={nonce3d}"/>
</form>
Values in curly brackets {} are variables which you need to replace with the values of the response.

Browsers and Languages

Languages

Based on the consumer’s browser language settings, the Hosted Payment Page, Embedded Payment Page, and Seamless Integration set the appropriate language automatically. The following table shows the supported languages:

Code English Name Local Name

ar

Arabic

عربي

de

German

Deutsch

en

English

English

es

Spanish

Español

fr

French

Français

it

Italian

Italiano

iw

Hebrew

עברית

ja

Japanese

日本語

ka

Georgian

ქართული

nl

Dutch

Nederlands

pl

Polish

Polski

ru

Russian

Русский

uk

Ukrainian

Українська

zh_CN

Chinese (simplified)

中文(简体)

zh_TW

Chinese (traditional)

中文(繁体)

Browsers and OS Versions
  • Chrome and Firefox update their browser almost every week. Thus, they do not provide any specific versioning in their browsers.

  • Chrome’s and Firefox’s browser updates automatically as soon as a new version is available and the user has restarted the browser.

Desktop
Manufacturers
Browser Name Manufacturer

Chrome

Google

Firefox

Mozilla

Internet Explorer

Microsoft

Safari

Apple

For desktop Wirecard supports the operating systems (OS) Windows and Mac OS.

The versions of the above mentioned browsers and OS can be combined as indicated here:

Browser Version and OS Version
Browser Name Browser Versions OS Platform OS Version Supported

Chrome

33.0 - Latest version

Windows

7 / 8 / 8.1 / 10

Firefox

28.0 - Latest version

7 / 8 / 8.1 / 10

Internet Explorer

8 - 11

7 / 8 / 8.1 / 10

Opera

12.15 - Latest version

7 / 8 / 8.1

Edge

14.0 - Latest version

10

Safari

8 - Latest version

Mac OS

Snow Leopard - Sierra

Mac OS

Mountain Lion - High Sierra

Mobile

On mobile devices Wirecard supports the OS Android and iOS. See below, which OS versions are supported.

OS Version
OS Platform OS Version Supported

Android

4 - Latest version

iOS

5.1. - Latest version

Redirect URLs and IPNs

Upon a successful or failed Wirecard Payment Page v1 transaction, the consumer is redirected (via automated HTTP POST) back to the successful or failed URL on the merchant’s site along with the digitally signed payment message (please refer to Response Signature.

We recommend to use IPNs. For details see Instant Payment Notification (IPN) to determine a transaction’s final status.

Default success and failure URLs are configured as part of the merchant account setup at Wirecard. You also can configure individual redirect URLs in a request. To amend these URLs, please contact merchant support.

Wirecard Merchant Support
Email: support@wirecard.com

Customization Options

Payment Page can be customized through a feature called Custom CSS URL,  which provides the option to use an external CSS file and link it to Payment Page.

This allows the Merchant to

  • customize the Payment Page by editing existing tag styles from an external css file

  • unhide optional fields on the credit card form

  • set up a custom logo 

  • send CUSTOM CSS URL per request as parameter

  • use a different CSS file per request

  • use multiple CSS files

All resources are stored on Merchant side. CUSTOM CSS URL needs to be part of the signature.
Advantages of Custom CSS URL

Next to the advantage, sending different types of CSS for different kind of requests, the merchant can customize his theme without requiring Wirecard’s permission. Nevertheless, the merchant’s development team is required to follow a few rules and restrictions, which do not present any kind of obstacles to get the page designed into the final theme.

How to use Custom CSS URL

The HPP, EPP, and Seamless Integration is set up to read a default css file embeddedHpp.css.  This file handles basic default color schemas. 

The main <form> container is based on BOOTSTRAP Grid systems, which are used to create page layouts through a series of rows and columns that house payment page content.

Developers can customize bootstrap.min.css, so while customizing a theme, the developer must follow bootstrap grid system usage rules.  For more details about bootstrap CSS conditions and usage please visit the bootstrap page http://getbootstrap.com/css/.

image

Custom CSS File Content Restrictions
For security reasons some elements are prohibited in the custom CSS file. The file must follow the criteria described below.
Custom CSS cannot contain the property -moz-binding.

CSS attributes beginning with - describe a proprietary attribute which may not be supported by all browsers. -moz-binding is an attribute used to load another XML file to describe the presentation of the selected element.   NOTE: If used, an error message appears: "Custom CSS contains not allowed property '-moz-binding'."

This code segment imports an external XML file to apply CSS properties.

invalid usage
body {
    -moz-binding: url("external-file.xml#xss");
}
Custom CSS cannot contain the property behavior.

The element behavior is an IE property with the same functionality as -moz-binding.

If used, an error message appears: "Custom CSS contains not allowed property 'behavior'."
invalid usage
body {
    behavior:url("script.htc");
}
Custom CSS cannot contain the property expression.

The reasons are the same as described for the properties -moz-binding and behavior.

If used, an error message appears: "Custom CSS contains not allowed property value 'expression'.
Custom CSS cannot contain the properties ::before and ::after.

The reasons are the same as described for the properties -moz-binding and behavior.

If used, an error message appears: "Custom CSS contains not allowed selectors ::after or ::before."
Custom CSS cannot contain the property url("javascript:.

Some CSS attributes support using url in their declaration. For example, it is possible to use a URL when setting the source of an image in CSS. Therefore it is prohibited to use this property. 

If used, an error message appears: "Custom CSS contains not allowed property value 'url("javascript:."
Custom CSS cannot include another CSS file called included.css.

In CSS, it is optional to import another stylesheet into the current stylesheet by prepending the file you want to include in a "@import" declaration at the start of the file. For example, the following CSS includes another CSS file called "included.css". This is not possible with Custom CSS.

If used, an error message appears: "Custom CSS contains not allowed @import directive."
invalid usage
@import url("included.css");
Custom CSS cannot use unknown directives.

Custom CSS can only use known directives.

If unknown directives are used, an error message appears: "Custom CSS has been evaluated as harmful because it contains unknown directive."
Custom CSS cannot use unknown properties.

Custom CSS can only use known properties.

If unknown properties are used, an error message appears: "Custom CSS cannot be parsed."
Custom CSS file and sources must reside on a server with valid SSL certificate.

The custom CSS file and all of the external sources need to be loaded from a  server which is running on a valid SSL certificate over HTTPS secured protocol.

If this condition is not fulfilled, an error message appears: "Custom CSS URL contains sources with absolute path which are not using HTTPS secure protocol."
valid usage with relative path to resource
/* ********** MAIN ELEMENTS THEMING - START ********** */
#hpp-logo {
/* customizing logo, this field could be hidden */
    height: 45px;
    width: 200px;
    float: right;
    background-image: url("../your-company-logo.png") !important;
    /* Caution: Path to CSS file sent in payment request is used as base URL */

    background-repeat: no-repeat;
    background-position: right top;
}
valid usage with absolute path to resource
/* ********** MAIN ELEMENTS THEMING - START ********** */
#hpp-logo {
/* customizing logo, this field could be hidden */
    height: 45px;
    width: 200px;
    float: right;
    background-image: url("HTTPS://www.your-company-site.com/your-company-logo.png") !important;
    /* Absolute path has been used over HTTPS protocol */

    background-repeat: no-repeat;
    background-position: right top;
}
Downloadable CSS Samples of Customized Themes

The following are some examples created to support the design of a customized page to show how certain changes are made. In order to get the default theme and to begin customizing an individual theme, simply delete the content of the custom CSS file. This is described below.

With a few lines of CSS you are able to change colors, transitions, backgrounds, etc. There is an option to add your own logo or picture with a custom location of the file.

image

As seen on the image below, there is an option to change bootstrap css properties. In the following example, the bootstrap .checkbox definition has been overlapped by this definition.

Sample
/* ********** CUSTOMIZING SEPA PAYMENT PAGE - START ********** */
/* Highlighting SEPA payment consent checkbox */
 #sepaDirectDebitForm.form-horizontal .radio, #sepaDirectDebitForm.form-horizontal .checkbox {
    min-height: 27px;
    background: #EDEDED;
    padding: 8px;
}
/* ********** ENABLING OPTION FIELDS - END ********** */

image

Dynamic CSS sample

An offline demo page, incuding comments, is available instructing how to customize specific tags to achieve a desired theme.

This example is located inside

wpg-dynamic-css-url.zip\wpg-dynamic-css-url\engine\custom\my-custom-name-css-embeddedHpp.css

which you can find here: wpg-dynamic-css-url.zip

For a more detailed description and to get more familiarized with all of the properties, please visit https://www.w3schools.com/css/ for more information.

Sample
/* ********** MAIN ELEMENTS THEMING - START ********** */
#hpp-logo {
/* customizing logo, this field could be hidden */
    height: 45px;
    width: 200px;
    float: right;
    background-image: url(your-company-logo.png) !important; /* Caution: relative path is not allowed. To reach proper functionality, image source file has to be called from absolute path over HTTPS secure protocol.*/
    background-repeat: no-repeat;
    background-position: right top;
}
.hpp-template, .hpp-nav > ul.nav > li.active > a {
    background: #5FD923 !important;
    color: white !important;
}
.hpp-template {
    background:-webkit-linear-gradient(#333333,#333333)!important;
    background:linear-gradient(#333333,#333333)!important;
    border: 1px solid #333333 !important;
}
.hpp-template-hover:hover, .hpp-template-focus:focus {
    background:#00D469!important;
    background:-webkit-linear-gradient(#00D168, #00964A)!important;
    background:linear-gradient(#00D168, #00964A)!important;
    box-shadow:0px 0px 11px #00994C!important;
}
#hpp-form-cancel{
background:maroon !important;
border: 1px solid maroon !important;
}
#hpp-form-cancel:hover, #hpp-form-cancel:focus {
   background:red important;
    background:-webkit-linear-gradient(red, red)!important;
    background:linear-gradient(red, red)!important;
    box-shadow:0px 0px 11px red !important;
}
.hpp-datepicker.datepicker-days td.active {
    background-color: #00A754 !important;
}
.hpp-nav > ul.nav > li.active > a::after {
    border-left-color:#00A754!important;
}
.hpp-loading-spinner {
    background: url('loading.gif') no-repeat; /* Caution: relative path is not allowed. To reach proper functionality, image source file has to be called from absolute path over HTTPS secure protocol.*/
}
.hpp-container .panel-heading {
    background: transparent none repeat scroll 0% 0%;
    -webkit-transition: background-color 0.4s;
    -moz-transition: background-color 0.4s;
    -ms-transition: background-color 0.4s;
    -o-transition: background-color 0.4s;
    transition: background-color 0.4s;
    cursor: pointer;
    cursor: hand;
}
.hpp-container .panel-heading:hover {
    background-color: #DBDBDB;
    -webkit-transition: background-color 0.4s;
    -moz-transition: background-color 0.4s;
    -ms-transition: background-color 0.4s;
    -o-transition: background-color 0.4s;
    transition: background-color 0.4s;
    cursor: pointer;
    cursor: hand;
}
/* ********** MAIN ELEMENTS THEMING - END ********** */
/* ********** ENABLING OPTIONAL FIELDS - START ********** */
#hpp-creditcard-form-row-for-street1-field {
    display : block;
}
#hpp-creditcard-form-row-for-street2-field {
    display : block;
}
#hpp-creditcard-form-row-for-city-field {
    display : block;
}
#hpp-creditcard-form-row-for-state-and-postalcode-fields {
    display : block;
}
#hpp-creditcard-form-row-for-country-field {
    display : block;
}
#hpp-creditcard-form-row-for-email-field {
    display : block;
}
#hpp-creditcard-form-row-for-phone-field {
    display : block;
}
/* ********** ENABLING OPTIONAL FIELDS - END ********** */
/* ********** CUSTOMIZING CREDIT CARD PAYMENT PAGE - START ********** */
/* Setting Optional text to italic and changing color to silver */
form#hpp-creditcard-form small[data-i18n~="optional"] {
    color: #D9D9D9;
    font-style: italic;
    font-weight: 900;
}
/* ********** ENABLING OPTION FIELDS - END ********** */
/* ********** CUSTOMIZING SEPA PAYMENT PAGE - START ********** */
/* Highlighting SEPA payment consent checkbox */
 #sepaDirectDebitForm.form-horizontal .radio, #sepaDirectDebitForm.form-horizontal .checkbox {
    min-height: 27px;
    background: #EDEDED;
    padding: 8px;
}
/* ********** ENABLING OPTION FIELDS - END ********** */
Dynamic CSS Sample - Flat Design

The flat design theme has been prepared for mobile users. Developers can completely change design, look, and structure of the payment page.

This example is located inside wpg-dynamic-css-url-flat-design.zip\wpg-flat_demo\index_files\FLAT-DESIGN-CUSTOM-embeddedHpp.css

which you can find here: wpg-dynamic-css-url-flat-design.zip

Sample Code
html, body, .hpp-container {
    height:99%;
}
*:not(.caret) {
    box-shadow:none!important;
    border:none!important;
    border-radius: 0!important;
}

.form-control {
    background: rgb(241,241,241) !important;
    color:rgb(85,85,85)!important;
}
.form-group input {
    background: rgb(241,241,241) !important;
    color:rgb(85,85,85)!important;
}
.panel-heading {
    padding:0;
    margin:20px 0 30px;
    display:none; /* JS managed visibility */
}
.panel, .panel-group, .panel-body{
    padding:0!important;
    margin:0!important;
}
.hidden-xs, .hidden-sm {
    display:none;
}

.hpp-template {
    background: #072C4A!important;
    color:#fff!important;
    font-size:14px!important;
}
.hpp-template-hover:hover, .hpp-template-focus:focus {
    background: #103757!important;
    box-shadow: none!important;
}
#hpp-header {
    display:none;
}
.hpp-btn-success {
    background: #14AF96!important;
    color:#fff!important;
    font-size:14px;
}
.hpp-btn-success:focus, .hpp-btn-success:hover, .hpp-template-bg .panel-heading a:hover {
    background:#16B89E!important;
}
.hpp-template-bg .panel-heading a {
    padding:13px 15px;
    background: #14AF96!important;
    color:white!important;
}
.hpp-container {
    width:100%;
    padding:0!important;
    margin:0 auto!important;
}
.hpp-container > div {
    padding-left:10px!important;
    padding-right:10px!important;
}
.hpp-btn {
    padding:10px 15px!important;
    font-size:21px!important;
    font-weight: bold;
}
.hpp-grid-selection {
    width: 175px;
}
.hpp-grid-selection > button > img {
    margin:5px;
}
.dropdown-menu {
    z-index:1002;
}
.hpp-grid-selection img,
.hpp-select2-lang-drop, .hpp-select2-drop,
.dropdown-menu {
    border:1px solid #f1f1f1!important;
}
.hpp-select2-lang-container {
    background: rgb(241,241,241) !important;
    color:rgb(85,85,85)!important;
}
.hpp-row-card-num > div:first-child {
    float:left!important;
    width:65%!important;
    padding-right:5px!important;
}
.hpp-row-card-num > div:nth-child(2) {
    float:right!important;
    width:35%!important;
    padding-left:5px!important;
}
.hpp-row-exp-date > div:first-child {
    display:none;
}
.hpp-row-exp-date > div:nth-child(2) {
    width:50%;
    padding-right:5px!important;
}
.hpp-row-exp-date > div:nth-child(3) {
    width:50%;
    padding-left:5px!important;
}
.hpp-white-glass {
    position:fixed;
    top:0;
    right:0;
    left:0;
}
#hpp-payment-methods > .hpp-white-glass > .hpp-loading-spinner {
    display:none!important;
}
#hpp-header {
    padding:0!important;
}
.hpp-form-title {
    background: #fff !important;
    color:rgb(85,85,85)!important;
}
.hpp-modal-confirm-dialog .hpp-form-title {
    text-align:center;
    margin:0;
}
#hpp-form-buttons {
    position:fixed;
    bottom:0;
    width:550px;
    margin:0!important;
    padding-top:5px;
    background:#fff;
    z-index: 1001;
}
#hpp-form-buttons > div {
    padding:0!important;
}
#hpp-confirm-dialog-buttons > .hpp-btn {
    width:50%;
}
#hpp-form-buttons > div:first-child {
     float:right!important;
     left:0;
     width:100%;
}
#hpp-form-buttons > div:nth-child(2)  {
    display:none;
}
#hpp-form-navigation {
    padding:0!important;
}
#hpp-form-navigation > div {
    border-spacing:0;
}
#hpp-payment-methods {
    margin-top:15px;
    position:relative;
    padding-bottom:70px!important;
}
#hpp-form-previous {
    border-left: 2px solid #fff !important;
}
form div[class^="col"] > label, form div[class^="col"] > label + small {
    display:none;
}
@media screen and (max-width: 560px), screen and (max-height: 560px),
  screen and (max-device-width: 560px), screen and (max-device-height: 560px) {
    #hpp-form-buttons {
        width:100%;
    }
}
image
image
image
image

Dynamic Custom CSS URL

This functionality has been implemented to overlap default styling definitions in embeddedHpp.css. and bootstrap.min.css. Custom css appears at the bottom of css files in the head tag.

This guarantees that existing bootstrap.min.css declarations are overlapped correctly.

Dynamic Custom CSS URL is an optional field named as custom_css_url which is also a mandatory part of the signature, in case that the merchant sends the custom_css_urlDynamic Custom CSS URL must meet the criteria mentioned below.

Length

Custom CSS URL must be shorter than 2000 characters including non-alfa-numerical characters.

In case of an error the developer is notified by an error message: "Custom CSS URL is too long - more than 2000 characters."
Characters

In general URIs as defined by RFC 3986 may contain any of the following characters: A-Z a-z 0-9 -._~:/?#[]@!$&'()*+,;=.

In case of an error the developer is notified by an error message: "Custom CSS URL has invalid format."
Size

Custom CSS file must be smaller than 50 kb.

In case of an error the developer is notified by an error message: "Custom CSS is too large. Max. 50 kB"
Format

Custom URL must be sent without any errors, or more precisely, the URL must have a valid format.

In case of an error the developer is notified by an error message: "Custom CSS cannot be fetched."
Invalid CSS Referencing
http://www.your-site.com/custom-style.css
http://www.your-site.com/custom-stylecss (missing dot: custom-style.css)
http://www.your-site.com/custom-style.php (php is unsupported postfix)
Valid SSL Certificate

Custom URL must be stored on a server, which is running on a valid SSL certificate. Custom CSS URL must be requested over HTTPS protocol.

In case of an error the  developer is notified by an error message: "Custom CSS URL must be loaded from HTTPS source with valid SSL certificate."
Invalid CSS Referencing
http://www.your-site.com/custom-style.css (only HTTPS URL is permitted)
Valid CSS Referencing
https://www.your-site.com/custom-style.css
Subsequent Request

Merchant is unable to request psp name and custom css url at the same time. If both are requested only custom css url will be accepted.

Identification

Merchant needs to create a digital signature on his own server as it is the only place where the secret is stored. The client’s server also provides the Merchant Account ID to the mobile app client.

To calculate the signature, following conditions need to be met:

  • Fields need to be concatenated,

  • Leading and trailing space removed,

  • SHA-256 signature follows the combined string.

The field order is important. Also: The values in the request signature must be identical with the client side form/data (with the exception of the secret key).
Order of the fields
1. request_time_stamp
2. request_id
3. merchant_account_id
4. transaction_type
5. requested_amount
6. requested_amount_currency
7. redirect_url (optional)
8. custom_css_url (optional)
9. ip_address (optional)
10. [secretkey]
The following is an example of request signature generation
request_time_stamp           = '20120430123012'
request_id                   = 'order-12345'
merchant_account_id           = 'b19fb056-d8da-449b-ac85-cfbfd0558914'
transaction_type              = 'purchase'
requested_amount             = '1.01'
requested_amount_currency    = 'USD'
redirect_url                 = 'https://test.com'
custom_css_url               = 'https://test.com/custom.css'
ip_address                   = '127.0.0.1'
secret_key                    = 'efabf47b-e43b-4785-873f-1c5bc65b7cd2'

Pre SHA-256 string
20120430123012order-12345b19fb056-d8da-449b-ac85-cfbfd0558914purchase1.01USDhttps://test.comhttps://test.com/custom.css127.0.0.1efabf47b-e43b-4785-873f-1c5bc65b7cd2

SHA-256 signature
a186cd295f5b0da14aa158090ee8abfcc1ca22961f2c19ea659c4a8f5cbb4a03

Input Fields for Credit Card

The following elements are mandatory/optional for sending a request for the payment method Credit Card. All of the optional fields are hidden by default. There is an option to unhide optional fields in Custom CSS by setting the value of the div ID parameter Display to block.

Term Man/Opt Type Value Div tag ID

First Name

O

Input

String

 #f_name_id

Last Name

M

Input

String

#l_name_id

Card Type

M

Select

String

Explicitly shown

Card Number

M

Input

Numerical

Explicitly shown

CVV

O

Input

Numerical

#cvv_id

Expiry Date - Month

M

Select

Numerical

Explicitly shown

Expiry Date - Year

M

Select

Numerical

Explicitly shown

Address (1)

O

Input

String

#hpp-creditcard-form-row-for-street1-field

Address (2)

O

Input

String

#hpp-creditcard-form-row-for-street2-field

City

O

Input

String

#hpp-creditcard-form-row-for-city-field

State/Province Postal Code/Zip

O

Input

String

#hpp-creditcard-form-row-for-state-and-postalcode-fields

Country

O

Select

String

#hpp-creditcard-form-row-for-country-field

E-mail

O

Input

Valid email address

#hpp-creditcard-form-row-for-email-field

Phone

O

Input

Valid phone number

#hpp-creditcard-form-row-for-phone-field

Example of usage optional email and phone fields for Credit Card
/* ********** ENABLING OPTIONAL FIELDS - START ********** */
#hpp-creditcard-form-row-for-email-field {
    display : block;
}
#hpp-creditcard-form-row-for-phone-field {
    display : block;
}
/* ********** ENABLING OPTIONAL FIELDS - END ********** */
image

Demo Shop

Read how you can use the Wirecard Demo Shop.

Payment Solutions

Merchants can offer payment on Hosted Payment Page (HPP) using a hyperlink from their own newsletter or simply an email. The hyperlink redirects the consumer to a credit card form within HPP in order to supply consumer’s card data. Additionally, the merchant can accept MOTO (Mail Order/Telephone Order) payments and remain PCI SAQ-A compliant. Pay by Link can also be used with the WPP integration.

Merchant can offer payment on Hosted Payment Page (HPP) which has been provided by hyperlink functionality for custom limited time by sending hyperlink_expiration_time_stamp in request. Timestamp is in ISO 8601 format consisting of combined date and time in UTC: YY-MM-DDTHH:MM:SS±HH:MM.

In order to generate payment link, send credit card payment request to REST API, specifically paymentmethods endpoint without entering card information. If request does not include all necessary parameters to execute the payment, URL to HPP card form is returned in the response. If request contains also optional hyperlink-expiration-time-stamp field, hyperlink will be valid until provided timestamp instead of default value of 30 minutes.

For XML and JSON Responses:

The response contains the actual path stored at <payment-method url> which renders card payment form. This path needs to be copied to customer.

XML authorization Request (Successful)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<payment xmlns="http://www.elastic-payments.com/schema/payment">
    <merchant-account-id>9105bb4f-ae68-4768-9c3b-3eda968f57ea</merchant-account-id>
    <request-id>3317a94b-c31a-a88d-4d03-ee5009f6cd44</request-id>
    <transaction-type>authorization</transaction-type>
    <payment-methods>
        <payment-method name="creditcard"/>
    </payment-methods>
    <requested-amount currency="EUR">10.15</requested-amount>
    <account-holder>
        <first-name>John</first-name>
        <last-name>Doe</last-name>
        <email>john.doe@test.com</email>
        <phone>5555555555</phone>
        <address>
          <street1>123 anystreet</street1>
          <city>Brantford</city>
          <state>ON</state>
          <country>CA</country>
          <postal-code>M4P1E8</postal-code>
        </address>
    </account-holder>
    <hyperlink-expiration-time-stamp>2018-12-07T13:20:00+02:00</hyperlink-expiration-time-stamp><!-- optional -->
</payment>
XML authorization Response (Successful)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<payment xmlns="http://www.elastic-payments.com/schema/payment" xmlns:ns2="http://www.elastic-payments.com/schema/epa/transaction">
    <merchant-account-id>9105bb4f-ae68-4768-9c3b-3eda968f57ea</merchant-account-id>
    <transaction-id>293d85c9-95ce-47f1-b82c-e4a8602e024f</transaction-id>
    <request-id>3317a94b-c31a-a88d-4d03-ee5009f6cd44</request-id>
    <transaction-type>authorization</transaction-type>
    <transaction-state>success</transaction-state>
    <completion-time-stamp>2018-11-19T11:50:36.000Z</completion-time-stamp>
    <statuses>
        <status code="201.0000" description="The resource was successfully created." severity="information"/>
    </statuses>
    <requested-amount currency="EUR">10.15</requested-amount>
    <account-holder>
        <first-name>John</first-name>
        <last-name>Doe</last-name>
        <email>john.doe@test.com</email>
        <phone>5555555555</phone>
        <address>
            <street1>123 anystreet</street1>
            <city>Brantford</city>
            <state>ON</state>
            <country>CA</country>
            <postal-code>M4P1E8</postal-code>
        </address>
    </account-holder>
    <payment-methods>
        <payment-method url="https://api-test.wirecard.com:443/engine/hpp/creditcard/293d85c9-95ce-47f1-b82c-e4a8602e024f/?request_time_stamp=20181119115036&amp;request_id=3317a94b-c31a-a88d-4d03-ee5009f6cd44&amp;merchant_account_id=9105bb4f-ae68-4768-9c3b-3eda968f57ea&amp;transaction_id=293d85c9-95ce-47f1-b82c-e4a8602e024f&amp;transaction_type=authorization&amp;requested_amount=10.15&amp;requested_amount_currency=EUR&amp;redirect_url=&amp;ip_address=&amp;request_signature=70a697bd993dc381cbea1b5263b55154cf7ec8872b4ed8d6bfcc9820fdd0f194&amp;psp_name=elastic-payments&amp;hyperlink_expiration_time_stamp=20181207112000&amp;country=CA" name="creditcard">
            <card-types>
                <card-type>jcb</card-type>
                <card-type>discover</card-type>
                <card-type>mastercard</card-type>
                <card-type>visa</card-type>
                <card-type>maestro</card-type>
                <card-type>amex</card-type>
                <card-type>diners</card-type>
                <card-type>upi</card-type>
            </card-types>
        </payment-method>
    </payment-methods>
    <hyperlink-expiration-time-stamp>2018-12-07T13:20:00+02:00</hyperlink-expiration-time-stamp>
</payment>
JSON authorization Request (Successful)
{
  "payment" : {
    "merchant-account-id" : {
      "value" : "9105bb4f-ae68-4768-9c3b-3eda968f57ea"
    },
    "request-id" : "{{$guid}}",
    "transaction-type" : "authorization",
    "requested-amount" : {
      "value" : 10.15,
      "currency" : "EUR"
    },
    "payment-methods" : {
      "payment-method" : [ {
        "name" : "creditcard"
      } ]
    },
    "hyperlink-expiration-time-stamp" : "2017-05-05T01:00:00.000+03:00"
  }
}
JSON authorization Response (Successful)
{
  "payment": {
    "statuses": {
      "status": [
        {
          "code": "201.0000",
          "description": "The resource was successfully created.",
          "severity": "information"
        }
      ]
    },
    "merchant-account-id": {
      "value": "9105bb4f-ae68-4768-9c3b-3eda968f57ea"
    },
    "transaction-id": "0430dd85-aa3f-45e7-85f5-d8dbfd370a80",
    "request-id": "1ce3fba5-5cfc-4b94-988a-3f6927055a03",
    "transaction-type": "authorization",
    "transaction-state": "success",
    "completion-time-stamp": 1493707087000,
    "requested-amount": {
      "value": 10.15,
      "currency": "EUR"
    },
    "payment-methods": {
      "payment-method": [
        {
          "card-types": {
            "card-type": [
              "hipercard",
              "amex",
              "uatp",
              "cartebleue",
              "diners",
              "aura",
              "maestro",
              "cup",
              "jcb",
              "discover",
              "visa",
              "mastercard"
            ]
          },
          "url": "https://api-test.wirecard.com:443/engine/hpp/creditcard/0430dd85-aa3f-45e7-85f5-d8dbfd370a80/?request_time_stamp=20170502063807&request_id=1ce3fba5-5cfc-4b94-988a-3f6927055a03&merchant_account_id=05fd7b10-2ccc-4e95-a790-ca9452153e37&transaction_id=0430dd85-aa3f-45e7-85f5-d8dbfd370a80&transaction_type=authorization&requested_amount=10.15&requested_amount_currency=EUR&redirect_url=&ip_address=&request_signature=d7e9ba9c032668299ba6ac7a03acbc192145bf9a4b4aa2e3ab14320e0cc20565&psp_name=elastic-payments&hyperlink_expiration_time_stamp=20170504220000&",
          "name": "creditcard"
        }
      ]
    },
    "hyperlink-expiration-time-stamp": 1493935200000
  }
}
  1. The payment hyperlink is valid until provided expiration timestamp. If expiration timestamp is not provided, hyperlink is valid only 30 minutes, then the request ID expires.

  2. The payment hyperlink may be used only once.

  3. Merchant must generate own <request-id> as for every request.

  4. Redirect URL must be specified. If merchant hasn’t been configured on merchant level configuration, redirect URL must be sent via request.

Invoice via Email

Invoice via Email allows the merchant to send the consumer a generated payment link automatically via email (or manually via other devices/units of the merchant’s choice).

Workflow
Workflow Email via Invoice
  1. The merchant logs in to the Wirecard Enterprise Portal.

  2. The merchant provides the required payment information.

  3. The merchant generates the URL.

  4. The merchant sends the URL to the consumer.

Custom URL: