Direct API Migration Guide
This document provides a comparison between the legacy Direct API and the new Direct API version, helping merchants understand the key differences and migration points.
1. API Domains
| Environment | Legacy Version | New Version |
|---|---|---|
| Production | https://hkg-online.everonet.com | https://api.evonetonline.com |
| Sandbox | https://hkg-online-uat.everonet.com | https://sandbox.evonetonline.com |
2. API Endpoints Comparison
| Operation | Legacy Version | New Version |
|---|---|---|
| Create Payment | POST /g2/v1/payment/mer/{sid}/evo.e-commerce.payment | POST /payment |
| Retrieve | GET /g2/v1/payment/mer/{sid}/payment?merchantTransID={merchantTransID} | GET /payment/{merchantTransID} |
| Get Interface Design | Each operation (e.g., capture, refund)has its corresponding GET interface | Unified use of GET /payment/{merchantTransID} |
3. Signature and Authorization
| Item | Legacy Version | New Version |
|---|---|---|
| Signature Method | Requires building a signature string, hashing it with SHA256, and including the result in Authorization. | Simplified authentication — no manual signature construction required. Use the Key at the store level directly in the Authorization header. |
| Key Configuration | Uses store-level keys but requires manual signature construction. | The system provides a KeyID, and SignType is Key-based. |
The same authentication type used in requests is also applied to responses and asynchronous notifications.
4. Transaction Flow Compatibility
The new Direct API keeps the same transaction flow as the legacy version, including:
- One-time payment
- Authorization and Capture
- Refund and Cancel operations
- 3DS authentication flow
Merchant can migrate without changing their existing payment flow logic.
The upgrade mainly simplifies API usage and improves consistency across payment scenarios.
5. Transaction Scenarios Comparison
5.1 One-Time Payment (With 3DS)
- Request Format: Identical
- Response Differences:
- Status standardization:
Verifying->verify_pending - issuingCountry location:
paymentMethod.card->paymentMethod - New events field: Includes transaction status history
- Other fields: Consistent
- Status standardization:
5.2 One-Time Payment (Without 3DS)
- Request Format: Identical
- Response Differences:
- New action field:
{"action": {"type": "completed"}} - Status standardization:
Captured->captured - issuingCountry location:
paymentMethod.card->paymentMethod - New events field: Includes transaction status history
- Other fields: Consistent
- New action field:
5.3 Recurring (First Transaction)
- Request Differences:
- Legacy: Includes
vaultID,tokenize, anduserReferenceunderpaymentMethod.card - New: Remove these fields, add top-level
userInfo.referencefile instead
- Legacy: Includes
- Response Differences:
- Unified response structure: Includes complete
paymentobject - Status standardization:
Verifying->verify_pending - issuingCountry location optimization
- New isNetworkToken field
- New events field: Includes transaction status history
- Other fields: Consistent
- Unified response structure: Includes complete
5.4 Recurring Subsequent Transaction
- Request Differences:
- Legacy: Includes
recurringReferencefield understand - New: Removes
recurringReferencefield (system automatically associates base on token)
- Legacy: Includes
- Response Differences:
- New action field
- Status standardization:
Captured->captured - issuingCountry location optimization
- New events field: Includes transaction status history
5.5 Authorization and Capture
- Request Format: Identical
- Response Differences:
- Status standardization:
Authorised->authorized - issuingCountry location:
paymentMethod.card->paymentMethod - New events field: Includes transaction status history
- New transInitiator field: Complete transaction initiator information
- Other fields: Consistent
- Status standardization:
6. Response Structure Improvements
The new Direct API includes minor response structure improvements while remaining backward compatible.
Key updates include:
- Payment status values are standardized using updated enumeration values. (for example,
Capturedbecomescaptured, andVerifyingbecomesverify_pending). - The
actionobject is always returned and indicated the next step of the transaction flow or whether the transaction has been completed. - The
issuingCountryfield is moved to thepaymentMethodlevel for better consistency. - Events Field: New field included in all responses, providing transaction status history.
Most integration continue to work without changes, though merchants using strict response parsing or hardcoded status checks may need minor updates. For detailed request and response parameters, please refer to the API reference: https://developer.evonetonline.com/reference/post_payment
7. Webhook Notification Comparison
- Status Value Standardization and refinement (e.g., verified, authorized)
- IssuingCountry Location optimization
- Additional Information: Include complete
transInitiatorfield - Notification Mechanism: Asynchronous notification sent at each finalized status
8. Result Code Mapping
Please refer to the documentation for the latest response code definitions: Result Code Reference
9. Compatibility
The legacy and new Direct APIs are highly compatible.
Request and response structures remain largely consistent, and existing payment integrations usually require minimal changes.
Merchants can migrate gradually without service interruption.
Migration Benefits & Next Steps
The new Direct API provides several improvements:
- Simpler integration: no manual signature construction required.
- Better consistency: unified transaction handling across payment flows.
- Future-ready design: new payment features will be introduced in this version first.
- Smooth migration: minimal changes needed for most merchants.
Merchants are encouraged to migrate to benefit from future enhancements and simplified maintenance.
For detailed integration instructions, please refer to the Direct API Integration Guide:
https://developer.evonetonline.com/docs/direct-api-integration
Updated about 14 hours ago
