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

EnvironmentLegacy VersionNew Version
Productionhttps://hkg-online.everonet.comhttps://api.evonetonline.com
Sandboxhttps://hkg-online-uat.everonet.comhttps://sandbox.evonetonline.com

2. API Endpoints Comparison

OperationLegacy VersionNew Version
Create PaymentPOST /g2/v1/payment/mer/{sid}/evo.e-commerce.paymentPOST /payment
RetrieveGET /g2/v1/payment/mer/{sid}/payment?merchantTransID={merchantTransID}GET /payment/{merchantTransID}
Get Interface DesignEach operation (e.g., capture, refund)has its corresponding GET interfaceUnified use of GET /payment/{merchantTransID}

3. Signature and Authorization

ItemLegacy VersionNew Version
Signature MethodRequires 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 ConfigurationUses 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

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

5.3 Recurring (First Transaction)

  • Request Differences:
    • Legacy: Includes vaultID, tokenize, and userReference under paymentMethod.card
    • New: Remove these fields, add top-level userInfo.reference file instead
  • Response Differences:
    • Unified response structure: Includes complete payment object
    • Status standardization: Verifying -> verify_pending
    • issuingCountry location optimization
    • New isNetworkToken field
    • New events field: Includes transaction status history
    • Other fields: Consistent

5.4 Recurring Subsequent Transaction

  • Request Differences:
    • Legacy: Includes recurringReference field understand
    • New: Removes recurringReference field (system automatically associates base on token)
  • 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

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, Captured becomes captured, and Verifying becomes verify_pending).
  • The action object is always returned and indicated the next step of the transaction flow or whether the transaction has been completed.
  • The issuingCountry field is moved to the paymentMethod level 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 transInitiator field
  • 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