Introduction
Features
- Embedded payment: generate card payment form in your payment page and let IOTPay handle the rest
- Redirected payment: be redirected to IOTPay page to create a transaction
- Direct payment: create a transaction with one api call (PCI compliance required)
Before Integration
Before integration, merchants need to sign a contract with IOTPay and get the merchant ID, merchant key and login name.
Terminologies and Concepts
Important
This document will refer to the following terms. Developers should familiarize themselves with these terms.
Concept | Definition |
---|---|
Merchant | A merchant onboard IOTPay |
Customer | A customer of a merchant of IOTPay (usually a buyer) |
JS SDK | A JS software library developed by IOTPay for merchants using their own payment page |
Redirected Integration | Protocol for merchants using IOTPay's payment page |
Embedded Integration | Protocol for merchants using their own payment page via JS SDK |
Token | Token representation of a customer card, can be used repeatedly for future API calls |
Tokenize | Making a request to Auth API for a token |
Purchase | Making a request to Auth API to create a transaction |
Channel | Different payment channels, currently supports PF_CC and UPI_EX |
secureId | A session identifier for Embedded integration protocol |
Request / Response format
All request and response are in JSON format. It should not be treated as fixed or as a schema, new fields may be added as the API evolves, and the order of fields may change. Your applications must therefore be resilient to the reordering of fields within a JSON object.
Integration Workflow
The flow is slightly different for the two methods, but it all starts with calling Auth API from the backend.