Implementation
Appendix A: Order Creation
Steps for Creating an Order
On Checkout:
The webshop saves the transaction in its database.
The status field is set to pending.
Set the Request Header:
Accept: application/jsonMake a CreateOrder POST Request:
POST https://test.mypayloft.com/MERCHANTIDReplace
MERCHANTIDwith your actual Merchant ID received via email.
You can also find your Merchant ID and Secret Key under
Settings > API Keys on the Payloft Onboarding Platform.Request Payload (JSON Format):
{ "amount": 100, "currency": 566, "description": "Your transaction description", "returnUrl": "http://yourwebsite.com/returnurl", "callbackUrl": "https://youwebsite.com/callbackurl", "secretKey": "5ASD599DFSA21SDS13S536SFS98968390", "fee": 0, "referenceID": "YourPaymentReference", "CustomerName": "Customer Name", "Email": "customeremail@domain.com", "isJson": "false" }Refer to Table 1.0 for field details.
Replace
secretKeywith the cryptographic key sent to you via email.Ensure that the
currencyfollows the ISO 4217 numeric standard.The
amountdisplayed to the customer must match the amount sent to the payment gateway.returnUrl: The URL where Payloft redirects the customer after payment.callbackUrl: The URL your server is notified on after payment completion.isJson: Determines the response format:true→ Data is returned via GETfalse(default) → Data is returned via POST
referenceIDYour own Transaction reference IDYou can include metadata such as your transaction ID, customer IP address, or other info in the
descriptionfield.
Example:"description": "Description of service^REF:123456(IP:41.8.29.132)"
Table 1.0
Field | Mandatory | Type | Max Length |
|---|---|---|---|
Amount | Yes | Decimal (18,2) | 18 |
Currency | Yes | Integer (ISO 4217 number) | 5 |
Description | Yes | VARCHAR | 150 |
returnURL | Yes | VARCHAR | 150 |
callbackURL | No | VARCHAR | 150 |
SecretKey | Yes | VARCHAR (255) | 500 |
Fee | No | Decimal (18,2) | 18 |
ReferenceID | No | VARCHAR | 150 |
CustomerName | Yes | NVARCHAR | 50 |
Yes | NVARCHAR | 50 |
Appendix B: Transaction ID Generation
Process Overview
Receiving the Create Order Request:
When a
Create Orderrequest is submitted, the Payloft Gateway (UP MPI) captures the following transaction details:amountdescriptionsecretKey(cryptographic key)Additional fields from the payload
Generating the Transaction ID:
The gateway creates a session with the submitted data.
A unique transaction ID is generated to represent the transaction.
This transaction ID is included in the response to the
Create Orderrequest.
Usage of the Transaction ID:
This ID must be included in all subsequent requests, such as:
Payment initiation
Transaction status queries
The webshop must store and use this ID for all operations related to the transaction.
Querying Transaction Details:
The Payloft Gateway uses the transaction ID to look up and return the transaction's current status and details.
Appendix C: Handling Transaction ID and Payment Redirection
After the Payloft Gateway (UP MPI) responds with a Transaction ID, complete the following steps to process the payment flow:
1. Update Webshop Database
Persist the Transaction ID returned in the
Create Orderresponse.Link the transaction ID to the relevant order record in your webshop’s database.
2. Redirect Customer to Payloft for Payment
Initiate an HTTP GET request to redirect the customer to the payment gateway.
Include the Order ID as part of the URL path.
Example: Payment Redirection URL
Appendix D: 3DSecure Provider
Definition
A 3DSecure Provider is an entity responsible for delivering 3DSecure authentication services, which help verify the identity of cardholders during online transactions.
Role of a 3DSecure Provider
A 3DSecure Provider can be:
A payment scheme such as:
Visa
Mastercard
Verve
A third-party service provider acting on behalf of the card Issuer.
Purpose
3DSecure authentication enhances the security of online card payments by reducing the risk of fraud through additional customer verification steps.
Appendix E: Payment Confirmation and Status Query
Payment Completion and Redirection
After the customer completes payment, UP MPI redirects them back to the application using the
returnUrlprovided during order creation.The redirection method depends on the
isJsonflag:false: Redirection occurs via HTTP POST.true: Redirection occurs via HTTP GET.
Parameters Sent to
returnUrl
UP MPI sends the following parameters in the redirection request:
You must query the Payloft Gateway server to obtain the correct status of the transaction.
To query the status of a transaction, send a GET request to the UP MPI server e.g.
https://test.mypayloft.com/Status/OrderId. WhereorderIdis the transaction ID sent as a response after the order was created.The payment gateway will respond with the complete detail of the transaction status in a json response. Below is a sample:
Store the raw/exact json response in the web shop’s database. This will be required for the resolution of disputes that may arise
Extract the information from the json response and make this visible on the transaction log table on the admin portal and customer transaction history view on the Webshop
Table 1.1 contains the details of the data in the response
Update the status of the transaction on the web shop’s database with the status of in the json response
Display a receipt to the customer showing the details of response received and send email as well to the customer. It is important to show the details of the response received in the receipt.
Table 2.0
Field | Type | Description |
|---|---|---|
OrderId | Integer | This is the same as the transactionId |
Description | String | Description of the product/service sent to the payment gateway |
Amount | Decimal (18,2) | The transaction amount |
TranDateTime | String | Transaction Date and time |
PAN | String | Masked Pan of customer |
Cardholder | String | Name of Cardholder |
Convenience Fee | Decimal (18,2) | |
Currency | Integer | ISO 4217 number of the transaction currency. |
ApprovalCode | String | The Approval Code only exists for approved transactions. |
Scheme | String | Scheme used by cardholder |
Status | String | Status of the transaction usually approved or declined |
StatusDescription | String | Description of the status |
Table 3.0
Status | Description |
|---|---|
Approved | A transaction is approved when the customer is successfully debited and value for transaction is received. |
Cancelled | A transaction is cancelled when the customer decides to not enter payment details and returns back to the merchant site. |
Declined | A transaction is declined when one of the following happens: |
Initiated | A transaction is initiated when the customer abandons a transaction at the beginning. |
EXPIRED | A transaction is expired when the customer abandons a transaction at the end. |
Appendix F: Callback Signature Verification
1. Verifying Payment Notification via x-api-key Header
When a payment is completed or updated, the Payloft Gateway (UP MPI) sends a POST request to your configured callbackUrl. This request includes:
A header (
x-api-key) containing yoursecretKeyA JSON body with the transaction data
2. Header Information
The signature is included in the x-api-key header of the callback POST request.
Header:
Body:
Need help or support during implementation? Contact our support team for assistance.