Skip to main content

Card Verification

Local Payments

Card Verification

Card verification is used to verify the payment account before payment: to confirm whether the account is valid and to determine whether the cardholder's name matches. Usually with API Payment Use it together, and initiate a payment after the card is verified.

1

Judgment process

Card inspection results are divided into three layers, which must be judged in order: When the previous floor is inconclusive, do not look at the next floor.

1orderStatus
PENDINGThe results are undecided, the platform will automatically retry; poll the query interface to get the results, no orders will be placed for the time being
FAILEDThe request itself failed (channel exception, parameter error, etc.) and can be re-initiated
SUCCESSRequest succeeded, proceed to the next level of judgment
→
2accountStatus

Judge only when success

VALIDThe account is valid, proceed to the next level of judgment
INVALIDInvalid account, do not initiate payment
UNKNOWNCan't determine if the account is valid, don't continue to judge the name
→
3accountNameMatchResult

Judge only when success + valid

MATCHName matches, can initiate payment
NOT_MATCHName mismatch, first check account name
UNKNOWNThe channel cannot determine whether the names match, it is recommended to check
note

FAILED only means that the verification request failed, not that the account is invalid. UNKNOWN means that a name was provided but the channel could not determine a match. When accountNameMatchResult=UNKNOWN, accountName may still be returned, and the platform passes it through unchanged.

2

Works with API payments

Payments on behalf of others Only identify the account, do not verify the payee name, it is recommended that you perform a card verification before making your first payment to an account:

  1. Get your payout account info.
  2. Call the card check and look up the final result.
  3. The account is valid and the name matches before initiating the payment; the other results are first checked against the account or account name.

Recommended actions for different card verification conclusions:

  • VALID + MATCH: Payments can be initiated.
  • INVALID or account UNKNOWN: Do not pay; verify the account or ask the user to use a different account.
  • NOT_MATCH or name UNKNOWN: Confirm the account name with the user, then decide according to your risk policy.
  • FAILED or PENDING: Handle verification first (retry / poll); do not place the order yet.
note

By validating the card, you only represent that the account is valid and the name matches. Not guaranteed Payments are always successful - payments can still fail due to insufficient funds, channel limits, risk blocking, and more.

3

Interface Guidelines

  • Initiate verification: POST /open-api/inquiry-account
  • Query verification result: POST /open-api/inquiry-account/query

The request structure is consistent with the payment interface (appId / sign / param). Focus on the following parameters:

SpecsDescription
countryCodeCountry code: ID / MY
mchOrderIdMerchant card verification order identification, unique
accountTypeAccount type, e.g. BANK / EWALLET / DUITNOWPROXY
accountNoPayout to: bank account, phone number, or DuitNow account
accountNameOptional; if provided, name matching is performed. If omitted, the result is null.

The response highlights orderStatus, accountStatus, and accountNameMatchResult; if the request fails, check failedCode / failedMessage.

note

ID (Indonesia) and MY (Malaysia) are currently supported. Account Verification must be enabled separately; contact your account manager.

For other fields and the complete enumeration, see the Account Verification API and the Query Verification Result API.