eZeeWallet

Adapter 0.1.0, documentation reviewed 2026-10-25. Overall status: limited.

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by unique_id and status.
• Delivery order: not documented by the provider.
• eZeeWallet documents no event id, retry schedule, ordering or duplicate behavior. Answer every notification with the NotificationEcho ({ unique_id }) and make the handler idempotent on unique_id (or transaction_id) and status; confirm the final state with GET /transaction before acting.

Known limitations

• Status words differ per endpoint and between the data types, examples and narrative of the reference (pending vs pending_async, succeeded / failed vs approved / declined). They are kept per endpoint, each with where it is documented, and are never merged into one state machine. A status not documented for the endpoint stays unknown.
• A transfer moves e-money from the consumer wallet to the merchant wallet in one step. An approved transfer is shown as a wallet payment, never as a card authorization; there is no authorize / capture split. A pending transfer means the consumer has not finished (for example must top up) and stays pending until a notification or lookup shows the result.
• The narrative describes a transfer Timeout, but its exact status string is not documented; such a status is shown as unknown.
• Notifications are thin (an id, status, signature and, when declined, decline_reason). decline_reason values are not documented: the text is shown as the provider wrote it and is never classified, so a declined notification is decoded with an unknown category.
• Notification signatures are SHA-1 of transaction_id and the merchant API username. They are sensitive, never copied and never verified; a pasted notification is not treated as authentic. Only the shape (40 hexadecimal characters) is reported. Which id is hashed for payout notifications is not documented.
• No response or notification carries a timestamp. No event time is invented; the timeline follows the input order, or receipt times supplied with the receivedAt envelope.
• eZeeWallet documents no event id, retries, ordering or duplicate behavior. Repeated notifications are recognized by unique_id and status only, because the payload carries nothing else; the notification content type is not documented (examples are JSON).
• Correlation uses ezw_reference_id and unique_id as separate keys, because the reference does not say whether they hold the same value. A refund links to its transfer through ezw_reference_id, the only documented parent reference. The legacy transfer response carries no eZeeWallet id; it links to its notification only through transaction_id, which eZeeWallet refuses to process twice (code 408). merchant_transaction_id and merchant_reference are never used as links.
• Error code is typed as a string but shown as an integer; both are read. Code 401 carries two different messages. The changelog entry for 2.0.1 (new error details) does not say which codes changed. Category and retry guidance per code are PandaPayLens suggestions.
• Reference examples contain trailing commas (not valid JSON). They are accepted with a LENIENT_JSON warning; other syntax errors are not repaired.
• Batch payout per-item results, credit payout request status strings (codes 417 to 421) and account status values other than the examples are not documented. The legacy batch payout response ({ unique_id, status }) is too generic to be detected without selecting the provider manually. The container key of GET /transfers list responses is not documented; list items are recognized when supplied one by one.
• No merchant sectors are documented. The consumer site splits wallet balances into gambling and non-gambling balances, but that is not a statement of merchant eligibility; eligibility depends on jurisdiction, licensing and underwriting.
• The regulated entity is unresolved: the About Us page names Prime Pay Solutions Limited (Isle of Man Financial Services Authority), the consumer terms name emerchantpay ltd. (UK Financial Conduct Authority, Reg. No. 900778). The list of Non-Supported Countries was not found in the public pages.
• No chargeback, subscription or rebill objects exist in the API. Consumer wallet funding (bank transfer and other methods) happens outside this API and is not shown.
• Payloads of the emerchantpay Genesis route (transaction_type ezeewallet, XML payment_response) are Genesis payloads, not eZeeWallet API payloads, and are never claimed by this adapter. Any record carrying transaction_type is left to other adapters.
• Account and balance responses carry account data and no payment lifecycle; account responses are recognized but not analyzed, balance responses are not recognized.

Examples

• eZeeWallet: transfer declined: A transfer notification with a declined status; the decline reason is shown as provider text.
• eZeeWallet: payout flow: A payout request and its status notifications.

Provider documentation

• eZeeWallet API reference (v2.0.2)
• eZeeWallet Slate public API docs (repository)
• eZeeWallet public site
• eZeeWallet for business
• emerchantpay Genesis API reference (eZeeWallet section, separate format)

PandaPayLens is not affiliated with eZeeWallet. Pasted notifications are never treated as verified: PandaPayLens does not check webhook signatures.