Direct Payment API

The request scenarios for both Direct Payout API and Checkout API are the same. However, the difference between both merchants is that with Direct Payout API, the customer isn’t redirected to the checkout page as the request and response are done directly from server to server. Also, there are additional parameters in which the merchant has to send when using this particular API such as the exact payment solution required, along with the account details of that particular customer. On the other hand, with the checkout page, the customer can always be redirected back.


For e.g. if a customer was to make a transaction using credit cards, the merchant would have to pass the customer’s credit card details as part of the process. EPG would then make a direct request to the appropriate provider in order to process the transaction and provide immediate feedback to the merchant. As long as the transaction does not require customer redirect, this method can also be used with any other payment solution.

Direct Payout API Sequence Diagram






Encryption Steps:

All of the requests are sent to EPG already encrypted due to security purposes. When using this type of API, EPG processes the transaction and provide feedback efficiently. If a transaction requires a customer redirection, then EPG will respong with the necessary URL needed to redirect the customer.
Once the customer transaction is complete, EPG then sends it back to the merchant. In continuation to this, merchants are to provide EPG with a list of IP addresses from which the server post will be formed.


Direct API Steps:


1. Once the merchant obtains a list of parameters, it should then be sent to EPG mapped together using the following format:


2. Once complete, a new string of parameters are to be encrypted using <strong>AEScipher</strong> algorithm. This method of encryption uses the merchant’s password which is previously set up by EPG. The password is to be hashed, using MD5 algorithm before encrypting the parameters.


3. Once the parameters are encrypted, the merchant is to perform a SHA256 Hashing of the original unencrypted parametes. This produces a value that EPG will use in order to check the integrity of the request.


4. The merchant is to post all of the data to EPG from their server. This is done by appending the newly created encrypted parameters, the merchantId in particular as provided by EPG and the integrity check to the URL.
An example of this is shown below:
encrypted=sd76sdghfdgdf76sugfdguyfgd7td7fgdf&integrityCheck=jhsjnbcjbxcjh232h2j3&merchantId =2150


5. After the IP is checked and it is valid, EPG will then attempt to decrypt the parameters and perform a SHA256 Hashing to make sure the integrity of the request is intact. If successful, EPG will then execute the request and respond to the merchant with the result. In the event that the solution requested requires a redirect of the customer, EPG will return a String that is the URL that the merchant has to use to redirect the customer. This is continued in the following step.


6. The merchant can redirect the customer using the URL provided by EPG. Below is an example of what the final redirection URL would look like:



Direct Payment API Response:

The difference between both APIs is only the response. Due to no redirection for the customer, there won’t be a success/error/cancel page. Instead, the merchant will obtain a synchronous response in which it is the same information posted in the status URL for the checkout API.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Payfrex-response operation-size="1">
     <message>WorkFlow has finished successfully, for transaction Id: 101134 </message>
         <operation sorted-order="1">    
            <details> <?xml version="1.0" encoding="UTF-   8"?> <netdirect version="4.1">
            <time>{ts'2013-12-10 15:51:16'}</time>
     </operations> <optionalTransactionParams> 


How to encrypt the request:

Throughout the merchant boarding process, EPG along with the merchant both have to agree on a password for encrypting the request. Once the password is set, it is then Hashed using MD5 algorithm. This password is only to be used for the encryption process and not be sent to the API or any other type of method. Full working examples of the encryption process can be found in the Appendix B of this document.
Example: SHA256
Password: 21fifty
SHA256(21fifty) = 2692a90ca3ff6dbcea1479461e116ce8

Once the Hash value of the password is available, the encryption process commences. AEScipher algorithm is used to perform the encryption process, in which this 2-way algorithm allows encrypting and decrypting.

In addition to this, all the parameters need to be encrypted except for the merchant identifier that will be posted unencrypted.
Examples of values before encrypted are shown below: (See parameters Appendix B):
Examples values after encrypted:

Once the steps mentioned above are complete, the merchant is to perform a SHA256 Hashing of the unencrypted parameters. This is so that EPG can perform an integrity check of the original parameters.
Final example request generated: pted= wohJ3qj85aN4m1GQzLtIWQCcURm6n&integrityCheck=sdkhg43kjhgqdfhbfeqwf


Cookies Policy We need our cookies to make EPG better. If you need more information click here.