Enterprise

Integration

Preparation for Integration to Enterprise

You can follow the below steps to prepare for integration to your website, shopping cart or application to the Enterprise solution:

1. For Test Account information, click here.
2. If you do not have a Live Account, please email our sales team.
3. Configure referral IP within the Wirecard Web Console.
4. Decide whether you are going use Real Time or Deferred Settlement Processing Methods.
   Note: Association rules state that if selling physical goods a merchant should use deferred settlement.
5. Decide whether you are going to use 3D Secure to help reduce fraudulent credit card transactions.
   Note: If you are going to integrate to 3D Secure refer to the 3D Secure Integration Guide.
   Note: 3D Secure is a mandatory requirement for certain banks.
6. Decide whether you are going to store credit card detail in your database or use the Wirecard Web Console or one of Wirecard's tokenization solutions to manage your transactions.
   Note: Wirecard does NOT recommend card storage. Please refer to PCI Standards for association rules related to card storage.
7. Integrate your website or shopping cart using your code, Wirecard sample code or Wirecard shopping cart code. Ensure that you are using the correct Merchant ID and Application ID issued to you on registration. Ensure that if you are testing using a Live Account that you are using Test Mode (0) when integrating for the first time.
8. Test Enterprise before you move to Live Mode (1) and go live with your site.

Registering for a Live Account

In order to register for a live account, you will need an internet merchant account and sign up for Wirecard's payment gateway services.

Test Account Details

For testing purposes, we have provided a MerchantUID and ApplicationUIDs in multiple currencies.

Note: If your merchant account is 3DS enabled, please ensure that you have integrated into the 3DS Lookup and Authenticate methods (Actions 14 and 15).

View all ApplicationUIDs

MerchantUID: F5785ECF-1EAE-40A0-9D37-93E2E8A4BAB3

When going live, these will need to be replaced in your code by using the Wirecard issued MerchantUID and ApplicationUID.

Web Service URL

The Web Service URL is the Wirecard API URL used to submit the web service to:

https://api.mygateglobal.com/api/

The Web Service WSDL is:

https://api.mygateglobal.com/api/?wsdl

Note: Mode 0 (test) and Mode 1 (live) can be used.

Note: Mode 1 must be used when going live.

Go Live Checklist

Overview

Use the Go Live Check List to make sure that you have completed all necessary tasks before going live. Please ensure that the following criteria have been met:

Configuration

1. Is your merchant account enrolled for 3D Secure or does your bank have mandatory requirements for 3D Secure? If so, have you completed 3D Secure Integration as the 3D Secure Transaction Index will be required in the Enterprise API message.
2. Authorise and Capture Integration Completed
3. Referral IP have been added in Wirecard Web Console
4. Merchant ID and Application ID of the “Merchant” (not test Merchant ID and Application ID) is being used in your message type.

Testing

1. Test 3D Secure Lookup and Authenticate

2. Test Authorise and Settle

3. Test transactions are visible in Wirecard Web Console

Go Live

1. Merchant received Go Live email from Wirecard. This email will contain the merchants Customer ID and Merchant ID .
   (If not, have merchant contact support.za@wirecard.com)

2. Ensure that you are using the Live URL.

3. Add referral IP address.

4. Web Service Mode have been changed from 0 to 1 (0 test / 1 live)

5. Perform Live transaction with Live card

Test Cards

Test Cards are used to perform test authorizations to Wirecard. Test Cards will only work when using Test Mode (0) in the live environment. Test Cards transactions will not go to the acquirer.

Test Card Types

• Visa
• MasterCard
• Amex
• Diner
• Maestro

Note: Test Cards will not work in Live Mode (Mode 1) in the Live Environment.

Non 3D Secure Test Cards

Visa Successful
Card Name	Joe Soap
Card Number	4111111111111111
Card Type	Visa
Expiry Date	Any date in future
CVV Number (last 3 digits on back of card)	any cvv
Visa Declined
Card Name	Joe Soap
Card Number	4242424242424242
Card Type	Visa
Expiry Date	Any date in future
CVV Number (last 3 digits on back of card)	any cvv
MasterCard Successful
Card Name	Joe Soap
Card Number	5100080000000000
Card Type	MasterCard
Expiry Date	Any date in future
CVV Number (last 3 digits on back of card)	any cvv
MasterCard Declined
Card Name	Joe Soap
Card Number	5404000000000001
Card Type	MasterCard
Expiry Date	Any date in future
CVV Number (last 3 digits on back of card)	any cvv
Amex Successful
Card Name	Joe Soap
Card Number	370000200000000
Card Type	AMEX
Expiry Date	Any date in future
CVV Number(last 3 digits on back of card)	any cvv

Amex Declined
Card Name	Joe Soap
Card Number	374200000000004
Card Type	AMEX
Expiry Date	Any date in future
CVV Number(last 3 digits on back of card)	any cvv
Diners Successful
Card Name	Joe Soap
Card Number	36135005437019
Card Type	Diners
Expiry Date	Any date in future
CVV Number(last 3 digits on back of card)	any cvv
Diners Declined
Card Name	Joe Soap
Card Number	36135182434011
Card Type	Diners
Expiry Date	Any date in future
CVV Number(last 3 digits on back of card)	any cvv
Maestro Successful
Card Name	Joe Soap
Card Number	5641821111166669
Card Type	Maestro
Expiry Date	Any date in future
CVV Number(last 3 digits on back of card)	any cvv
Maestro Declined
Card Name	Joe Soap
Card Number	6759411100000008
Card Type	Maestro
Expiry Date	Any date in future
CVV Number(last 3 digits on back of card)	any cvv

3D Secure Test Cards

Visa Successful
Card Name	Joe Soap
Card Number	4000000000000002
Card Type	Visa
Expiry Date	Any date in future
CVV Number (last 3 digits on back of card)	any cvv
Visa Failed
Card Name	Joe Soap
Card Number	4000000000000010
Card Type	Visa
Expiry Date	Any date in future
CVV Number (last 3 digits on back of card)	any cvv
MasterCard Successful
Card Name	Joe Soap
Card Number	5200000000000007
Card Type	MasterCard
Expiry Date	Any date in future
CVV Number (last 3 digits on back of card)	any cvv
MasterCard Failed
Card Name	Joe Soap
Card Number	5200000000000023
Card Type	MasterCard
Expiry Date	Any date in future
CVV Number (last 3 digits on back of card)	any cvv

Test CCV

As additional account security, every credit card comes with a special three or four digit code generally known as a CVV2 or CVV number. Cardholders will be requested to enter this when processing an online payment. An identity thief who has come across credit card information illegally will not have access to the CVV number if they do not have physical access to the card.

Wirecard Response Codes

Enter the full response code below:

View all Response Codes

API Definitions

Message Overview

Illustration: Transaction Overview

1. The card holder clicks a “Pay-Now” button on the merchant website after having filled in their credit card information. The merchant website or application does a web service call to the Wirecard 3D-Secure API, calling the 3DS Lookup (Action 14).
2. The 3DS Lookup response will include a status field.
3. In the event that the status field value is equal to “0” or “1”, you will continue to step 5 below.
4. In the event that the status field value is equal to “-1”, the transaction was unsuccessful. You should display an appropriate message to the card holder at this time.
5. In the event that the  authRequired field = “Y” in the 3DS Lookup Response (Action 14), you will need to redirect your card holder to an URL (returned in step 2 as the acsUrl field) by means of a form POST. It is at this stage that the card holder will be prompted for their 3D-Secure OTP (One Time PIN). A sample form POST is available here.
6. In the event that the authRequired field = “N”, you can attempt an authorization by invoking the Wirecard Enterprise API calling the Authorise (Action 1) or a Sale (Action 5). Note that this field needs to be read in conjunction with the liabilityShift field to determine the risk of this transaction.
7. After the card holder has entered their 3D-Secure OTP, they will be posted back to your website or application.
8. You can call the 3DS Authenticate (Action 15) to receive the payload or proceed directly to attempt an Authorise or Sale (Actions 1 or 5). Please note that you will then populate the paresPayload field with the values received from the ACS response.
9. If you called a 3DS Authenticate (Action 15), Wirecard will return a response back to your website or application.
10. In the event that the status field value from the 3DS Authenticate response is equal to “0” or “1”, and the paresStatus is equal to “Y”, “A” or “U”, you will call the Wirecard Enterprise API,  using Authorise (Action 1) or Sale (Action 5). The paresStatus field value needs to be read in conjunction with the liabilityShift field to determine the risk of this transaction.
11. In the event that the status field value from the 3DS Authenticate response (Action 15) is equal to “-1” or the paresStatus value is equal to “N”, the transaction was unsuccessful. You should display an appropriate message to the card holder at this time.
12. Wirecard will attempt to perform an authorisation on the submitted card details and return a transaction response.
13. If an Authorise (Action 1) was processed and the status field value returned in step 12 is equal to “0” or “1”, you may attempt to perform a Capture (Action 3) on the authorised transaction. If this step is not performed, the transaction will not be settled and the money authorised on the card holders account will not be paid over to you. If a Sale (Action 5) was performed and the status field value returned is equal to “0” or “1”, the transaction was successful and the will be paid over to you.
14. In the event that the result returned in step 12 is equal to “-1”, you can deduce that the transaction was unsuccessful. You should display an appropriate message to the card holder at this time.
15. Wirecard will attempt to settle the requested transaction and will return a response to your website or application.
16. In the event that the status field value from step 15 is equal to “0” or “1”, the transaction was successful. You may display an appropriate message to the card holder in this case.
17.  In the event that the status field value from step 15 is equal to “-1”, the transaction was unsuccessful. You should display an appropriate message to the card holder at this time. Read through the response data to determine the reason for the failure and to rectify before re-submitting a Capture, as the funds has been reserved on the customer’s card.

Message Definitions

Message definitions describe the general purpose, type, routing, and response information of each of the Wirecard API message type. Each Wirecard API message has 2 portions;

• Header
• Body

Request Message (Header)

The below table represents the header portion of the Message that the API supports.

XML	Data Type & Length	Presence	Comments	Example Data
<Header>
<authenticate>
<merchantUID>F5785ECF-1EAE-40A0-9D37-93E2E8A4BAB3</merchantUID>	GUID	M	Each merchant is issued MerchantUID by Wirecard.  This identifies who the merchant is on Wirecard's Back Office System.	F5785ECF-1EAE-40A0-9D37-93E2E8A4BAB3
<merchantToken>F5785ECF-1EAE-40A0-9D37-93E2E8A4BAB3</merchantToken>	GUID	M	A merchant token is linked to your website or application.  Your default token is the MerchantUID issued to you by Wirecard.	F5785ECF-1EAE-40A0-9D37-93E2E8A4BAB3
<actionTypeID>1</actionTypeID>	Integer (2)	M	This is used to identify what action should be performed.	1
<authenticate>
</Header>

Example XML Soap Header

<Header>
    <authenticate>
        <merchantUID>F5785ECF-1EAE-40A0-9D37-93E2E8A4BAB3</merchantUID>
        <merchantToken>F5785ECF-1EAE-40A0-9D37-93E2E8A4BAB3</merchantToken>
        <actionTypeID>1</actionTypeID>
    <authenticate>
</Header>

List of Message Types (Actions)

The below table represents the message body message types that the API supports and indicates the entity that originates the message type.

Message Type	Action Type	Comments	Processor
Authorise	1	The  Authorise message creates a request to hold the requested amount and mark it as unavailable from the customer's card until it is either Captured or the hold terminates, thus rendering the amount available again.	MG, AB, SB, NB, FNB, BC
Authorise – Reversal	2	The Authorise – Reversal Message releases the hold that the Authorize placed on the customer's credit card funds. Use this service to reverse an unnecessary or undesired Authorisation. You can use full Authorise – Reversal only for an authorisation that has not been captured.	MG, AB, SB, NB, FNB, BC
Capture	3	When you are ready to fulfil a customer's order, Capture the Authorisation for that order.	MG, AB, SB, NB, FNB, BC
Sale	5	A sale is a bundled authorization and capture. You can use a Sale instead of a separate Authorise and Capture if there is no delay between taking a customer's order and shipping the goods.	BC
Credit Capture	4	A Follow-On Credit is linked to a Capture in the system. You can request multiple Follow-On Credits against a single Capture. This action would reverse a Capture – Action 3.	MG, AB, SB, NB, FNB, BC
Credit  Sale	12	Credit Request messages are generated when a merchant wants to return the funds after  a transaction that has been captured (refund of a Sale - action 5).	MG, BC
3DS Lookup	14	This message is used to verify if the issuer and cardholder participates in 3D Secure program.	MG, AB, SB, NB, FNB, BC
3DS Authenticate	15	This message is used direct the card holder to their banks authentication page where they will validate the transaction using their secret password.	MG, AB, SB, NB, FNB, BC
Reports	19	The Report request exposes console and internal database reporting via an API call and returns the data in an xml format.	MG, AB, SB, NB, FNB, BC
Visa Checkout	20	This action is used when payment is made via Visa Checkout	MG, AB, SB, NB, FNB
Create Token	21	This message is used when creating a token	MG, AB, SB, NB, FNB, BC
Read Token	22	This message is used when reading a token	MG, AB, SB, NB, FNB, BC
Delete Token	23	This message is used when deleting a token	MG, AB, SB, NB, FNB, BC
Update Token	24	This message is used when updating a token	MG, AB, SB, NB, FNB, BC

Processor List
Abbreviation	MG	AB	FNB	SB	NB	BC

API Explorer and Sample Code

Request Message (Body)

This section describes the mandatory, conditional, optional data element layouts for all message types (Actions) that the API supports.

3DSecure Lookup (Action 14)

This message is used to verify if the issuer and cardholder participates in 3D Secure program.

Sample XML Request

Reference Reference

3D Secure

Wirecard offers the 3D Secure service to all of its merchants. If you are using Enterprise, you may be required to integrate to Wirecard's 3D Secure API which is included in this document.

Wirecard's payment platform is integrated to 3D Secure enabling transactions to be processed to both the MasterCard Secure Code & Verified by Visa 3D Secure schemes.

3D Secure stands for Three Domain Secure - the payment industry's internet authentication standard which has been developed by the major card schemes. Visa has called their version of the scheme 'Verified by Visa' and MasterCard have called their equivalent initiative 'MasterCard Secure Code'. These are both collectively referred to as 3D Secure.

Note: In order for a merchant to share the benefits of 3D Secure, they must request that their internet merchant account be 3D Secure enabled.

Note: 3D Secure is mandatory with certain banks.

3D Secure Transactional Process

The 3D Secure process consists of a web service call followed by a form post. Each call can bring back variable results that will form part of the next process.

High Level 3D Secure Transaction Process:

Step 1 - Shopper browses at merchant site, adds items to shopping cart, then finalizes purchase.

Step 2 - The merchant will invoke a web service (3DS Lookup) to the Wirecard's API.

Step 3 - Wirecard sends query including card number to Directory Server. This leg of the process is also commonly known as VERes.

Step 4 - If card number is in a participating card range, Directory Server queries appropriate Access Control Server (ACS) to determine whether card number is enrolled.

Step 5 - ACS responds to Directory Server, indicating whether authentication is available for the card number.

Step 6 - Directory Server forwards ACS response (or its own) to Wirecard.

Step 7 - Wirecard's will return a 3DS Lookup Response to the merchant. If cardholder is not enrolled in 3D Secure or if authentication is otherwise unavailable, the merchant submits a traditional authorization request and the 3D process ends.

Step 8 - Based on the result (issuer or card type participating), merchant initiates a form post (3DS Authenticate) that posts the values retrieved from the 3DS Lookup Response (first web service call) to the Access Control Server (ACS) via the shopper's browser.

Step 9 - ACS authenticates shopper as appropriate for the card number then formats the ACS Result message with appropriate values and digitally signs it.

Step 10a - ACS returns an ACS result (PARes) to merchant via shopper's browser.

Step 10b - ACS sends a copy of the Payer Authentication Response to the Authentication History Server.

Step 11 – Merchant process the result with authorization request to Wirecard.

Illustration: 3D Secure Process

Sample ACS Form POST

<form name="frmLaunchACS" method="POST" action="">
    <textarea cols="50" rows="5" style="width:400" name="PaReq" >
    </textarea>
<input type="text" style="width:400" name="TermUrl"
    <!��?��?��?This is the merchant URL that the form POST returns to ��?��?��?>      	value="http://www.merchant.com/3DSecure_Enterprise_Complete.php?Step=2"/>
    <input type="text" style="width:400" name="MD" value=""/>
    <input type="submit" value="Submit Form" style="width:250" >
</form>

This Form POST will return TransactionIndex and paresPayload values once the cardholder has correctly entered their OTP. These values will be entered into the Authorise or Sale actions (Actions 1 or 5).

Illustration: OTP Page

Understanding Electronic Commerce Indicators (ECI)

The ECI indicates the security level associated with an Internet purchase transaction. The 3DS Lookup & 3DS Authenticate requests will return an ECI in the response message which the merchant can use to gauge risk associated with the transaction. The payment gateway will process the ECI to the acquirer or its processor for inclusion in the authorization request message.

Note: Some ECI indicators will allow liability shift for certain transactions relating to chargebacks.

Note: Merchants can request that Wirecard block specific ECI's that do not allow for liability shift.

Dispute evidence

Merchants are recommended to store the below data as evidence in the event of a chargeback dispute relating to 3D Secure processing. The below data is returned on the 3DS Lookup & Authenticate responses.

Dispute Situation	ECI	Evidence
Proof of Authentication or Authentication Attempt	5,6,1 or 2	Minimum, if available:
		·   Purchase Date and Time
		·   XID
		·   Purchase Amount
		·   Order Description
		·   Transaction Status
		·   ECI
		·   Signature Date & Time
		·   CAVV / AAV

3D Secure Calls

The merchant will be required to initiate three 3D Secure calls as defined below:

3DS Lookup: This message is used to verify if the issuer and cardholder participates in 3D Secure program.

3DS Authenticate: This message is used to direct the card holder to their banks authentication page where they will validate the transaction using their secret password.

Time Outs

3DS Lookup

The standard timeout value for the 3DS Lookup to complete is ten seconds.

3DS Authenticate

The 3DS Authenticate Request message has no timeout value as it relies on the merchant's eCommerce application to determine maximum time frames for various shopping session activities.

3DSecure Authenticate (Action 15)

This message is used direct the card holder to their banks authentication page where they will validate the transaction using their secret password.

Example XML Request

Reference Reference

Authorise/Sale (Action 1,5)

The Authorise message creates a request to hold the requested amount and mark it as unavailable from the customer's card until it is either Captured or the hold terminates, thus rendering the amount available again.

A sale is a bundled authorization and capture. You can use a Sale instead of a separate Authorise and Capture if there is no delay between taking a customer's order and shipping the goods.

NOTE: Action 5(Sale) currently only works with VISA Africa. For all other banks use an Action 1 (Authorize) followed by an Action 3(Capture)

Example XML Request

Reference Reference

Capture (Action 3)

When you are ready to fulfil a customer's order, Capture the Authorisation for that order.

Example XML Request

Reference Reference

Auth Reversal (Action 2)

The Authorise – Reversal Message releases the hold that the Authorize placed on the customer's credit card funds. Use this service to reverse an unnecessary or undesired Authorisation. You can use full Authorise – Reversal only for an authorisation that has not been captured.

Example XML Request

Reference Reference

Credit (Actions 4,12)

A Follow-On Credit is linked to a Capture in the system. You can request multiple Follow-On Credits against a single Capture. This action would reverse a Capture – Action 3.

Credit Request messages are generated when a merchant wants to return the funds after a transaction that has been captured (refund of a Sale - action 5).

Example XML Request

Reference Reference

Reporting (Action 19)

The Report request exposes console and internal database reporting via an API call and returns the data in an xml format.

Example XML Request

Reference Reference

Visa Checkout (Action 20)

This message is used when payment is made via Visa Checkout.

Example XML Request

Reference Reference

Visa Checkout

Visa Checkout provides a single sign-in service to pay for online shopping purchases. After a simple setup, Visa Checkout users can skip inputting their payment and shipping information for their orders.

Visa Checkout Process Flow

1. Merchant calls VCO with unique user ID (CallID)
2. VCO returns the encrypted payload containing the user's card details to the Merchant
3. The Merchant calls the Wirecard API and passes the VCO payload using Action 20
4. Wirecard retrieves the Merchants External Client ID
5. Wirecard sends the CallID to VCO
6. VCO sends Decrypted Payload to Wirecard
7. Wirecard sends the transaction to the Acquirer
8. Wirecard sends Acquirer response to VCO and the Merchant

View complete VISA Checkout documentation

Tokenization

Introduction

Tokenized card payments offer the card holder a simplified checkout experience. The solution caters for customers that repeatedly purchase goods or services from a merchant’s website by simplifying the checkout experience. The solution will tokenize the card holder’s details during the initial transaction. For subsequent transactions, the card holder is only required to enter their CVV to process the payment making the checkout process more simplified. At any point, the card holder can amend card details, which will update the token with the new card information.

Tokenization Features

• The merchant is required to utilize TLS protocol 1.2 and above
• Merchant hosts their own payment page
• The merchant controls each and every phase of the transaction
• The online payment integration is fully incorporated into an existing website
• Advanced development skills are required
• Cardholder only has to enter CVV on subsequent transactions.
• The Fraud Module can be configured to help reduce fraud.

Overview of Tokenization actions

1. Merchant passes the cardholders details to Wirecard via the Create Token action.
2. Wirecard stores the card details and returns a token to the merchant.
3. Merchant can now use the returned token to process payments for the cardholder.
4. The cardholder only needs to supply their CVV number for future payments.
5. Merchant uses the Read Token action to validate the expiry date before using the token for future payments.
6. Merchant can update the token details using the Update Token action.
7. The token can be deleted using the Delete Token action.

Create Token (Action 21)

This message is used when creating a token.

Example XML Request

Reference Reference

Read Token (Action 22)

This message is used when reading a token. This action can be used to check if a supplied token exists or to validate the cards expiry date.

Example XML Request

Reference Reference

Delete Token (Action 23)

This message is used when deleting a token.

Note: To get a successful result from this action, first call action 21 (createToken) and replace {token-to-be-deleted} with the returned token.

Example XML Request

Reference Reference

Update Token (Action 24)

This message is used when updating a token.

Example XML Request

Reference Reference

Download Sample Code

Select your sample code package below:

Solution	View Code
Enterprise	View Code
Enterprise Tokenization	View Code
Visa Checkout	View Code

Integration Support - Configuration

Integration Support

Merchants

If you are a merchant that has signed up with Wirecard's Enterprise solution, you will have access to Wirecard's Integration Help Desk for telephonic and email support. Telephonic support is available 8am to 5pm GMT +2. Email support is 8am to 5pm GMT + 2 and connects directly to our help desk through our ticketing system.

Introduction to Enterprise

Enterprise allows the developer to remain in complete control over the entire payment process. The cardholder never leaves the merchants environment. Enterprise is a high performance TCP/IP payment solution that resides on your server. You can build your own API and use a web service to access the Wirecard server.

Enterprise relies on web services for the processing of transactions. A web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-process able format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards.

Enterprise requires that TLS protocol 1.2 or higher is enabled active in your application. The details of the transactions are passed to the Wirecard Payment Gateway from your website using web services. This is an efficient method of ensuring that any payment page is neatly under the control of an organisations website and an excellent way to micromanage even the smallest of details. When combined with TLS, a secure platform emerges which can be designed to work proficiently with any payment solution.

Enterprise Features

• The merchant is required to utilize TLS protocol 1.2 and above
• The merchant hosts their own payment page
• The merchant controls each and every phase of the transaction
• The online payment integration is fully incorporated into an existing website
• Intermediate development skills are required
• Email confirmation can be sent to cardholder for successful purchases.
• The Fraud Module can be configured to help reduce fraud.

Enterprise Payment Process

One of the main benefits of utilising the Enterprise Solution is the control over the payment page and entire payment process. It requires a higher level of integration as the merchant may be required to form part of the 3D Secure transaction process if their merchant account is 3D enabled.

Enterprise requires that the merchant host their own payment page. Once the transaction is received by Wirecard, it is then processed to the acquiring bank for authorization. The authorization message is then returned to the merchant.

Illustration: Enterprise Payment Process

Step 1 – Cardholder makes purchase from merchant's website.
Step 2 – Merchant displays payment page.
Step 2 – Merchant uses a web service to transmit data utilizing TLS protocol to Wirecard
Step 3 – Wirecard receives the transaction request and performs validation on the credit card detail and other  
Data elements submitted.
Step 3 – Wirecard processes the transaction to merchant Bank.
Step 4 – The merchant bank processes the transaction and returns a successful or declined message to
Wirecard.
Step 5 – Wirecard returns this result and/or error code with error description back to the Merchant
Website address specified in the Web Service call.
Step 6 – If the notifications are enabled, (from the Wirecard Web Console) Wirecard will notify the merchant by
email of the transaction details.
Note: The entire transaction process takes around 3 seconds.
Note: The above diagram and transaction process does not include the 3D Secure process.

General Requirements for Using Enterprise

• Website – You must have a website or shopping cart and have ability to load sample code or shopping cart code to the site.
• TLS – Your app must utilize TLS protocol 1.2 and up
• Internet Merchant Account – You are required to have an internet merchant account with a bank.
• Internet Connectivity – Internet connectivity is required to transmit the transaction.
• Static IP – The IP address that the web service call is coming from must be static.
• Wirecard issued Merchant ID and Application ID – Required data elements when sending your web service call.

Internet Merchant Account

An Internet Merchant Account is required to accept credit card transactions over the internet. If you have an Internet Merchant Account you need to supply these details to Wirecard before going Live. If you do not have an Internet Merchant Account, Wirecard can assist you with your application to the acquirer (bank).

Note: An Internet Merchant Account is a different type of merchant account than what is used for card present / POS transactions.  You will need to apply for an Internet Merchant Account even if you already accept credit card transactions from your store.

Security – Server Passwords

You need to apply security best business practice to ensure that confidential data and card detail are protected while either being stored in the database or while data is being transmitted. It is suggested that you encrypt key information issued to you by Wirecard such as merchant ID, application ID and transaction index.

Note: To reduce fraud or potential incidents it is recommended to encrypt any password that gives access to your server.

TLS

TLS (Transport Layer Security) and its predecessor, Secure Sockets Layer (SSL), both frequently referred to as "SSL", are cryptographic protocols that provide communications security over a computer network.

The Enterprise Solution requires a TLS 1.2 protocol or above to be enabled in your app before live transactions can be processed. Without this protocol, Wirecard will automatically fail any live transactions that are being submitted.

Card Storage

Storing of credit card detail is not recommended. Wirecard offers numerous payment solutions that enable merchants to maintain control over payment processing without storing card.

Note: Refer to Wirecard's Tokenization Solutions.

Note: Refer to PCI Standards for rules behind storing of card detail.

Payment Page Handling Best Practice

This section highlights best business practices when it comes to handling credit card information on your "Payment Page". These practices will aid in reducing cardholder finger error and also provide ability for some validation before processing to Wirecard.

Card Number Field

• Only allow "numeric" in the card number field. If alpha is in field, transaction will fail.
• Perform Luhn Check - The Luhn algorithm or Luhn formula, also known as the "modulus 10" or "mod 10" algorithm, is a simple checksum formula used to validate a variety of identification numbers, such as credit card numbers. The algorithm is in the public domain and is in wide use today.

Card Expiry

• Only display "current" and "future" dates.

Card Type

• Only display card types (MasterCard, Visa etc.) that you have been loaded by Wirecard to accept. In the event that you process a card type that is not loaded, you will receive an error back.
• Note: By default you are only loaded with MasterCard and Visa. Other card types may require application to relevant card association.

Failure / Success Page

When a transaction is completed the cardholder should be directed to a page that shows if the transaction was successful or declined. This is called the failure / success page. This allows the cardholder to identify whether the transaction was successful or not. The logic relating to which page to display is determined by the merchant based on the Transaction Result returned by Wirecard. In the event that the transaction result is declined, you can also display a message description informing the cardholder why the transaction was declined.

Configuring Enterprise

Configuration is controlled from within the Wirecard Web Console. Certain configuration is "mandatory" in order to begin trading live. Configuration for the payment gateway can be found under settings within the Wirecard Web Console. (refer to Settings – Gateway below)

NOTE: The Referral IP must be configured in the Wirecard Web Console in order for web service to be accepted. This is only required in Live mode.

Settings - Gateway

Gateway settings are used to configure the Wirecard payment solutions.

Illustration: Settings - Gateway

Configure Settings – Enterprise Solution

Within this section you can configure the IP Address that you will be calling from.

Configure Settings - Referral IP (mandatory)

The Referral IP address is the IP address that your application is being sent from. The IP address must be a static IP address. The IP address must be added in the configuration menu in order for your web service call to be accepted by Wirecard.

How to Add Referral IP

1. Go to "Products" tab and click "Payment Gateway".
2. In the left hand column click "Settings".
3. In the left hand column click "gateway".
4. Click the "configure settings" icon on the application that you want to configure.
5. Enter the IP address in the text box next to the add IP address label.
6. Click on the 'add' button.
7. Click on the "save" button at the bottom of the screen.

Payment Instruments

In this section the various payment instruments supported are listed. These are updated regularly as new payment instruments are integrated to the Wirecard platform.

Supported Payment Types

• Credit Cards
• Pinless Debit Cards

Supported Credit Cards

• Visa
• MasterCard
• Amex
• Diners

Supported Currencies

• BWP - Botswana Pula
• GHS -Ghanaian Cedi
• KES Kenyan Shilling
• USD - US Dollar
• SCR - Seychellois Rupee
• TZS - Tanzanian Shilling
• UGX - Ugandan Shilling
• ZMW - Zambian Kwacha
• MZN – Mozambican Metcal
• NGN - Nigerian Naira
• GBP - British Pound
• EUR - Euro
• MUR - Mauritian Rupee
• ZAR – South African Rand

Supported Transaction Types

The below lists the different credit card transaction types that Wirecard supports:

• Authorize
• Sale
• Authorization Reversal
• Capture (Settle)
• Credits / Refunds
• 3DS Lookup
• 3DS Authenticate

Wirecard Web Console

The Wirecard Web Console is used by merchants to manage payment gateway transactions. The console is full of rich features enabling transactional management of any Wirecard's solution or integration methods. A merchant will be issued with a user name and password for the web console when they sign up with Wirecard.

From within the Wirecard Web Console you can:

• Manage Configuration & Settings
• Manage Transactions
  • Authorize
  • Capture Transactions
  • Credits / Refunds
  • Authorization Reversals
• Reporting

Credit Card Processing Methods

The credit card transaction process is defined mainly by an authorization and a capture. An authorize request is processed to the acquirer who in turn on processes to the issuer. If the transaction is approved / successful the issuer will reserve the funds on the credit card for 21 working days. This is called an authorization. In order for you to receive your funds (settlement), a capture request is required.

To Capture an Authorized transaction, you can either:

• Send a capture request using the Capture Message Type in the web service request.
• Log into the Wirecard Web Console to manually capture the transaction.

Association Processing Rules

MasterCard and Visa require that the settlement of a credit card transaction takes place at time of delivery of the purchased product or service. If you are providing a product or service with real time delivery then deferred settlement is not required and a "Sale" action type can be used.

Real Time – Processing (Sale)

If you are delivering a product or service in real time, then you can use the Sale action type processing call which means you can perform one web service call that will include the authorize and capture request in the same API call.

A Sale action type eliminates the need for two web service calls (Authorize and Capture) to Wirecard. A Sale action type only requires one web service call to Wirecard.

The process is as follows:

1. Your website captures the credit card details from the cardholder.
2. You perform a Sale action type call to Wirecard via a web service.
3. Wirecard processes an authorization to the bank.
4. If the authorization is successful, Wirecard processes a capture message and the transaction is flagged to be settled to the bank in the next batch period.

Deferred Settlement – Processing (Authorize Call)

If you are delivering a product or service in arrears, then you can use the "Deferred Settlement" process which means you will first send an authorize request to reserve the funds of the credit card. When you have delivered the goods or service you can send a capture request or capture in the Wirecard Web Console. Upon capture, Wirecard will submit the transaction for settlement to the bank.

Note: Go to https://www.wirecard.co.za/payment-solutions/payment-gateway/online-payments/ to find out more about deferred settlement.

Transaction Type Processing

It is important to note that certain transaction types can be processed either by the "web service" or through the "Wirecard Web Console".

From the Wirecard Web Console merchants can process:

• Credits / Refunds
• Captures
• Manual Authorizations for MOTO environment

Note: The Wirecard Web Console caters for a high level of security, user permissions and processing limits for Credits / Refunds and Captures. Based on the merchants requirements, integration to certain transaction types may not be necessary as they can be managed through the Wirecard Web Console.

Note: It is recommended that you use the Wirecard Web Console for these specific transaction types to reduce risk and potential error.

Transaction Result

The transaction result is the transaction response returned from the request web service when sending any message type request to Wirecard. The transaction result informs you whether the transaction was successful or declined. The transaction result is often used to display to the cardholder on the failure / success page. Wirecard provides declined reason codes, error messages and in-depth message descriptions that can be displayed to merchant on the failure / success page.

Transaction Result Types

• Successful: Successful means that the transaction was successfully processed by the acquirer / bank.
• Successful with Warning: Successful with warning means that the transaction has successfully been processed by the acquirer. The warning has been triggered by the transaction being flagged by the fraud module. This will only occur in the event that the merchant has configured the fraud module to "flag" a transaction. This particular transaction result is used to "warn" the merchant of a potential fraudulent transaction.
• Bank Declined: Bank declined transactions are transactions declined by the bank. Generally, the bank that declines the transaction is the issuing bank and NOT the acquiring bank. There can be numerous reasons why the bank declines a transaction with most common ones being insufficient funds and invalid card detail.
• Wirecard Declines: Wirecard Declined transactions are transactions declined at Wirecard before sending to bank. The main declined reasons are fraud module rules, incorrect integration and invalid data being populated in the web service.