My Enterprise

My Enterprise allows the developer to remain in complete control over the entire payment process. The cardholder never leaves the merchants environment.

Integration

Preparation for Integration to My Enterprise

You can follow the below steps to prepare for integration to your website, shopping cart or application to the My 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 MyGate 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 MyGate Web Console or one of MyGate's tokenization solutions to manage your transactions.
    Note: MyGate 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, MyGate sample code or MyGate 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 My 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 MyGate'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 MyGate issued MerchantUID and ApplicationUID.

Web Service URL

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

https:// api.mygateglobal.com

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 Intergration Completed

  3. Referral IP have been added in MyGate 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 MyGate Web Console

Go Live

  1. Merchant received Go Live email from MyGate. This email will contain the merchants Customer ID and Merchant ID .
    (If not, have merchant contact support@mygateglobal.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 MyGate. 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)   123  
       
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)   123  
       
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)   123  
       
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)   123  
       
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)  123
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)  123
   
Diners Successful
Card Name Joe Soap
Card Number 
362135898197781
Card Type Diners
Expiry Date  Any date in future
CVV Number(last 3 digits on back of card)  123
   
Diners Declined
Card Name Joe Soap
Card Number 
360569309025904
Card Type Diners
Expiry Date  Any date in future
CVV Number(last 3 digits on back of card)  123
   
Maestro Successful
Card Name Joe Soap
Card Number  6759649826438450
Card Type Maestro
Expiry Date  Any date in future
CVV Number(last 3 digits on back of card)  123
   
Maestro Declined
Card Name Joe Soap
Card Number 
6700649826438450
Card Type Maestro
Expiry Date  Any date in future
CVV Number(last 3 digits on back of card)  123

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)   123  
     
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)   123  
     
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)   123  
     
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)   123  

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.

MyGate Response Codes

Enter the full response code below:

View all Response Codes

API Definitions

Message Overview

Transaction 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 MyGate 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 MyGate 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), MyGate 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 MyGate 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. MyGate 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. MyGate 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 MyGate API message type. Each MyGate 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 MyGate.  This identifies who the merchant is on MyGate'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 MyGate. 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

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.

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.

Capture

3

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

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.

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.

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

3DS Lookup

14

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

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.

Reports

19

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

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

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

MyGate'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 MyGate's API.

Step 3 - MyGate 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 MyGate.

Step 7 - MyGate'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 MyGate.

3D Secure Process 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).

OTP Page

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

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

Request Message Body (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

Download Sample Code

Select your sample code package below:

Integration Support - Configuration

Integration Support

Merchants

If you are a merchant that has signed up with MyGate's My Enterprise solution, you will have access to MyGate'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 My Enterprise

My Enterprise allows the developer to remain in complete control over the entire payment process. The cardholder never leaves the merchants environment. My 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 MyGate server.

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

My Enterprise requires that SSL is active on your website. The details of the transactions are passed to the MyGate 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 SSL, a secure platform emerges which can be designed to work proficiently with any payment solution.

My Enterprise Features

  • The merchant is required to install an SSL certificate
  • 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.

My Enterprise Payment Process

One of the main benefits of utilising the My 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.

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

Pay Process

Illustration: My 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 using SSL to MyGate
Step 3 – MyGate receives the transaction request and performs validation on the credit card detail and other  
Data elements submitted.
Step 3 – MyGate processes the transaction to merchant Bank.
Step 4 – The merchant bank processes the transaction and returns a successful or declined message to
MyGate.
Step 5 – MyGate 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 MyGate Web Console) MyGate 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 My Enterprise

  • Website – You must have a website or shopping cart and have ability to load sample code or shopping cart code to the site.
  • SSL – You must host your own SSL
  • 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.
  • MyGate 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 MyGate before going Live. If you do not have an Internet Merchant Account, MyGate 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 MyGate 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.

SSL

SSL (Secure Socket Layer) is a security protocol that ensures that data being captured on your website cannot be read by encrypting the data using two encryption keys.

The My Enterprise Solution requires a SSL Certificate to be installed on your web server before live transactions can be processed. Without this certificate, MyGate will automatically fail any live transactions that are being submitted.

Note: A SSL Certificate can be obtained from your website hosting company or developer.

Card Storage

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

Note: Refer to MyGate'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 MyGate.

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 MyGate 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 MyGate. 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 My Enterprise

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

NOTE: The Referral IP must be configured in the MyGate 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 MyGate payment solutions.

Gateway Settings

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

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 MyGate 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 MyGate supports:

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

MyGate Web Console

The MyGate Web Console is used by merchants to manage payment gateway transactions. The console is full of rich features enabling transactional management of any MyGate'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 MyGate.

From within the MyGate 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 MyGate 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 MyGate. A Sale action type only requires one web service call to MyGate.

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 MyGate via a web service.
  3. MyGate processes an authorization to the bank.
  4. If the authorization is successful, MyGate 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 MyGate Web Console. Upon capture, MyGate will submit the transaction for settlement to the bank.

Note: Go to http://mygate.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 "MyGate Web Console".

From the MyGate Web Console merchants can process:

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

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

Note: It is recommended that you use the MyGate 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 MyGate. 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. MyGate 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.
  • MyGate Declines: MyGate Declined transactions are transactions declined at MyGate before sending to bank. The main declined reasons are fraud module rules, incorrect integration and invalid data being populated in the web service.

API Reference

Close