BOLD.Pay Payment Gateway
Use this skill for BOLD.Pay (MACROKIOSK) payment integration work.
Source
Read references/boldpay-api.md before giving factual API guidance or writing integration code. BOLD.Pay has no public API reference; that file is distilled from the official MACROKIOSK WordPress.org plugin source (v1.7.1) and lists the endpoint catalogue, every request and response field, the AccessToken algorithm, requery, status and error codes, and what is not documented.
Read references/account-setup.md when the user asks how to register, where the username and API key live, Domain/IP Restrictions, WooCommerce plugin setup, sandbox access, channels, pricing or settlement.
Read references/source-map.md when choosing which source file backs a fact, or to see coverage and gaps.
Core Workflow
- Identify environment: sandbox (
uat.pay.etracker.cc) or live (pay.etracker.cc). - Identify surface: WooCommerce plugin (use it as is), OpenCart/EasyStore plugin, or custom integration that mirrors the plugin protocol.
- Confirm portal setup: approved BOLD.Pass username, API key, and your domain and server IP in Domain/IP Restrictions.
- Create a local pending payment first with expected amount (2 decimals, ringgit), a new unique
PayID, theCustIPyou will send, and the callback and notification URLs used. - Compute
AccessTokenserver-side:UPPER(MD5(UPPER(Username + "4" + Amount + CustIP + PayID + CallbackURL + NotificationURL + ApiKey))). - Redirect the browser to
PaymentRequest?with all fields (URLs and text URL-encoded). - On browser return or notification, recompute the token from stored values and compare (constant-time).
- Call
QueryRequestserver-side and read the result from the redirectLocationquery string. - Check query
TransactionID,OrderNumber,PayIDmatch, then settle idempotently on queryStatus=SUCCESS. - Reply
OKto the notification POST.
Core Facts
- Live payment page:
https://pay.etracker.cc/BoldPayApi/PaymentRequest. - Sandbox payment page:
https://uat.pay.etracker.cc/BoldPayApi/PaymentRequest. - Status query:
https://pay.etracker.cc/BoldPayApi/QueryRequest(sandbox hostuat.pay.etracker.cc; plugin useshttp://there, HTTPS also answers). - Create payment is a browser GET redirect with a query string, not a JSON API.
- Request fields:
AccessToken,Username,CustIP,PymtMethod(4),Amount,Description,CustName,CustEmail,CustPhone,OrderNumber,PayID,CallbackURL,NotificationURL,ApiKey,Origin,CurrencyCode. CurrencyCode:1MYR,3THB.- Amount is ringgit with exactly 2 decimals, not sen.
- AccessToken is uppercase hex MD5 of the uppercased concatenation; URLs are raw (not encoded) inside the hash.
- Response fields:
AccessToken,TransactionID,OrderNumber,PayID,Status,Reason,PymtMethod,IssuingBank. - Status values:
SUCCESS,PENDING,FAIL,REFUNDED,REVERSED; rejected requests return a numeric error code instead. - Channel codes:
CC,DD(online banking),WA(e-wallet),BNPL,OTC. - QueryRequest params:
AccessToken,APIKey,Username,PayID,CallBackUrl(note casing). - Notification is a server POST; reply body
OK. - API key lives in BOLD.Pass > Admin Management > Business Setting > API Key.
- No refund, recurring, instalment-field or payout API is published.
Critical Rules
- The response
AccessTokenis the request token echoed back. It does not signStatusand it was visible in the browser URL. Never settle from callback fields alone; always settle fromQueryRequest. - Recompute the token from stored expected values (amount,
CustIP, URLs), never from values in the callback. - Keep TLS verification on for
QueryRequest(the plugin turns it off; do not copy that). - The API key appears in the payment URL by design. Lock it down with Domain/IP Restrictions and rotate it if leaked.
- Generate a fresh
PayIDper attempt; reuse returns 416. - Send
CustPhoneas digits only. - Use one stable
CustIPper payment and store it; the token breaks if it changes between request and callback. - Make settlement idempotent: browser return and notification both arrive for the same payment.
- Never move a paid order back on a late
PENDINGorFAIL. - Do not quote fees, limits, or settlement times; they are per merchant agreement.
Completion Criteria
A BOLD.Pay integration is done only when:
- The token is built server-side and matches the documented order; a known-good sandbox payment succeeds.
- Local pending record stores
PayID, amount, currency code,CustIP, callback and notification URLs. - Callback and notification handlers recompute and compare the token in constant time.
- Every state change is confirmed by
QueryRequest, withTransactionID,OrderNumber,PayIDmatched. - Duplicate return plus notification settle once.
- Error-code returns (no
AccessToken) leave the order unpaid and are logged. - Tests cover bad token, wrong amount, query mismatch,
FAIL,PENDING,REFUNDED, duplicate notification andSUCCESS. - Deployment docs list
BOLDPAY_USERNAME,BOLDPAY_API_KEY,BOLDPAY_ENV, callback and notification URLs, server IP, and the Domain/IP Restrictions step.
Loophole Review Loop
When asked whether a BOLD.Pay strategy is "100% confident", run this loop until no factual gaps remain:
- List trust boundaries: browser redirect URL, BOLD.Pay hosted page, callback return, notification receiver, QueryRequest call, database, fulfilment job, BOLD.Pass portal settings.
- Check bypasses: forged callback with a copied token,
Status=SUCCESSwithout query, query skipped onFAIL, amount changed in the URL, reusedPayID, changed callback URL breaking in-flight tokens, sandbox/live mix, TLS off on query, leaked API key, duplicate notification, latePENDINGafterSUCCESS, refund done in portal not reflected locally. - Add fixes: stored-value token recompute, mandatory QueryRequest, strict field matching, unique
PayID, per-payment stored URLs and IP, idempotent settlement, Domain/IP Restrictions, TLS on, refund/reversal handling. - Re-read
references/boldpay-api.mdsections relevant to any gap. - State remaining uncertainty: no public API guide,
Originvalue for custom integrations,PymtMethodmeaning, notification retry policy, sandbox credentials, limits, refund process. Tell the user to confirm these with MACROKIOSK.


