Drop-in Integration Step
🚀 Drop-in Integration: From Zero to Global Payments in Minutes
Welcome to the elite way of handling payments. This guide walks you through the Drop-in SDK and API—a lightweight, high-performance integration that handles the heavy lifting of security and UI while you focus on building your business.
The core steps and data flow of the integration process are shown in the following figure. You can flexibly participate in the modules according to your actual needs.
🛠 Phase 1: Setting the Stage (Client-side)
Goal: Drop a secure payment frame into your site with zero CSS stress.
1. SDK Integration
Include our lightweight JavaScript engine via CDN. It is recommended to use our provided index.min.js as a fallback in case the CDN fails to load.
Latest version:
https://cdn.jsdelivr.net/npm/cil-dropin-components@latest/dist/index.min.js2. Adding Drop-in to an HTML container
Place a simple container in your HTML. This is where the Drop-in UI will elegantly materialize.
<div id="dropInApp"></div>⚡ Phase 2: Igniting the Engine (Server-side & Initialization)
Goal: Secure a handshake between your server and ours.
3. Fetch the "Golden Ticket" (SessionID)
Before initializing the DropInSDK, you must first obtain the sessionID from interaction API By Calling interaction API, you can decide the transaction expiry time, transaction type, user's data to collect.
NoteTransaction authentication of the interaction interface is completed through the SignKey (in the Authorization request header) and KeyID in the request header.
- Security First: Authenticate using your SignKey and KeyID in the headers.
- The Payload: Define the amount, currency, and transaction type.
- The Result: Your server receives a unique sessionID—pass this to your frontend to unlock the payment vault.
💡If you aim to create a subscription payment
- The below parameter is mandatory for creating subscription payment
| Field | Type | Value |
|---|---|---|
| userInfo.reference | String | Unique user reference number, it could be user member id register from your website |
| paymentMethod.recurringProcessingModel | String | Subscription |
- Save the Token
- After payment is completed, store the
tokenfrom either payment response API or webhook. - Store the token.value in your system and bind it with
userInfo.reference.
Example
{
"userInfo": {
"reference": "your_user_reference"
},
"paymentMethod": {
"recurringProcessingModel": "Subscription"
}
}4. DropIn SDK Initialization:
Initialize the DropInSDK using the sessionID obtained from the previous step and other necessary parameters to render the payment interface and process user delivery:
Here is the minimum mandatory value to initialize the SDK. Let's check from SDK reference to get more optional and default setting.
| Field | Type | M/O | Description |
|---|---|---|---|
| id | String | M | Fixed value: #dropApp |
| type | String | M | Fixed value: payment |
| sessionID | String | M | The sessionID returned by the interaction (LinkPay) API (16-character UUID in current LinkPay URL) |
| environment | String | M | Set the environment for requests, e.g., HKG_prod, BKK_prod, TYO_prod, UAT |
| mode | String | M | fullPage or embedded or bottomUp |
Example
const sdk = new DropInSDK({
id: '#dropApp',
type: 'payment',
sessionID: 'your-session-id',
locale: 'en-US',
mode: 'embedded',
environment: 'UAT',
appearance: {
colorBackground: '#fff'
},
payment_completed: handlePaymentCompleted,
payment_failed: handlePaymentFailed,
payment_not_preformed: handlePaymentNotPreformed,
payment_cancelled: handlePaymentCancelled
});📡 Phase 3: Mastering the Lifecycle (Handling Results)
There are 2 ways to reflects the latest status of order, SDK events and Webhooks. While SDK events can is an instant browser-side notification used to update your UI immediately; and Webhooks are server-to-server messages to update the final transaction status, which can be retry to ensure your database stays in sync even if the customer goes offline. Both are important and necessary tools for catching-up the order situation.
5. Handling Payment Callbacks
Process the payment callback returned by the DropInSDK, record key data (such as merchantTransID), update the UI, and trigger subsequent operations.
✅ payment_completed: Success! Store the merchantTransID immediately—you’ll need it for future refunds or status lookups.
❌ Other Error Handling: Use the returned message to show friendly, actionable tips to your users if a payment fails.
Event Name | Triggered by | Details Returns | What to Do |
|---|---|---|---|
payment_completed | When payment is successful | type: 'payment_completed', merchantTransID, sessionID |
|
payment_failed | When payment is failed / declined. | type: 'payment_failed', merchantTransID, sessionID, code, message |
|
payment_not_preformed | When payment is not executed (e.g. user does not complete the payment process) | type: 'payment_not_preformed', merchantTransID, sessionID, code, message |
|
payment_cancelled | When the user cancels the payment | type: 'payment_cancelled', sessionID |
|
For the full specification of SDK event, please refer to SDK Event Reference.
6. Handling Payment Webhooks:
Set the webhook endpoint from step 4 to receive asynchronous notifications from Evonet. Notifications typically contain the following fields:
| Field | Type | M/O | Description |
|---|---|---|---|
| result | Object | M | payment status |
| merchantOrderID | String | M | The unique Drop-in order ID generated by the merchant, to check order status |
| merchantTransID | String | M | The transaction ID created by Evonet, to query refund API to refund. |
| status | String | M | Order status code, used to update the database order status |
For parameters, please refer to API Explorer interaction Notification.
NoteAfter receiving a notification, the plain text "SUCCESS" must be returned to indicate successful receipt. If no response is received, the system will periodically resend asynchronous notifications at the specified frequency (15/15/30/180/1800/1800/1800/1800/3600 seconds) until a "SUCCESS" message is received or the maximum number of notifications is reached.
7. Using Drop-in for Subscriptions
It is possible to use Drop-in to setup subscription scenario, the integration flow is about the same as above, only few minor adjustments as below:
First Time Subscription:
-
Change in the 4th step (Obtain sessionID) When calling the Interaction API, use the following parameters:
{ "userInfo": { "reference": "your_user_reference" }, "paymentMethod": { "recurringProcessingModel": "Subscription" } } -
Save the Token
- After payment is completed, store the
tokenfrom either webhook or payment response API. - Store the
token.valuein your system and bind it withuserInfo.reference.
- After payment is completed, store the
Subsequent subscription (MIT Transaction)
- Use the Payment API to initiate the transaction.
- The request parameters must include (see the Appendix Payment API interface for details):
{ "paymentMethod": { "token": { "value": "Previously saved token value" }, "recurringProcessingModel": "Subscription" } } - Order Tracking:Use
merchantTransIDto track the order ID of the subsequent payments. - Capture transactions:
- Set
captureAfterHoursto 0 for immediate capture - If this field is not provided, the merchant must later call the
POST /captureAPI to perform manual capture.
- Set
8. Other Value-Added Drop-in Functions
- Recurring & Subscriptions -
- Card Bin Verification - to validate a customer’s card number before enabling payment. To support merchant perform additional business-specific validation before the transaction proceeds.
9. Other Optional APIs:
Using GET /payment/{merchantTransID} to query a payment status, merchantTransID is obtained from payment.merchantTransInfo.merchantTransID
For authorized transactions, this API can be used to carry out capture POST /payment/{merchantTransID}/capture
For transaction that is captured, use POST /payment/{merchantTransID}/refund to carry out partial or full refund of the transaction.
Updated about 3 hours ago
