emerchantpay

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 (plus event and chargeback_unique_id for dispute notifications), or wpf_unique_id and wpf_status for WPF notifications; Genesis notifications carry no event or delivery id; emerchantpay documents that notifications can be delivered more than once.
• Delivery order: not documented by the provider.
• Answer each notification with the notification_echo XML carrying its unique_id (or wpf_unique_id) so Genesis stops resending it, make the handler idempotent per unique_id and status, and reconcile the transaction before acting on it.

Known limitations

• Payment responses are read from XML documents with root payment_response (also as the body of a raw HTTP response) and from JSON objects with the same fields. One XML document is one response. XML values are text: amount must be an integer in minor units as documented, and a field PandaPayLens reads that arrives as an element with attributes, child elements or repeats makes the record invalid. WPF create and reconcile XML (wpf_payment), notification_echo acknowledgements, reconcile and Processing API requests (payment_transaction) and blacklist responses are recognized and reported as unsupported, because the research does not record their fields or they carry no payment result. Genesis XML inside a JSON string is recognized but not read; paste the XML itself.
• Detection is structural. The same Genesis platform also runs as another operator's instance (E-ComProcessing, per the official PHP SDK), with identical payloads; without a hostname a payload can only be identified as the Genesis platform, not as emerchantpay specifically. Hostnames and brand names are never used for detection.
• Notifications have no event id, delivery id or timestamp. The delivery key is the field combination suggested by the research (unique_id + status, plus event + chargeback_unique_id for disputes; wpf_unique_id + wpf_status for WPF); two genuinely different notifications with equal values are treated as repeated deliveries. Notification events have no event time, so their order is the input order.
• Genesis resends a notification periodically until it receives the notification_echo XML. The retry interval, the maximum number of attempts and the delivery order are not documented.
• Processing notifications carry no currency, so their amount is shown in minor units without a currency. The processing notification content type is not documented; its examples start with ? like a query string. Documentation examples split over several lines with leading & cannot be imported as-is; join them into one line.
• Signatures (SHA-1, SHA-256 or SHA-512 of the unique_id and the API password) are never verified, copied or reported; only the signature length class is shown. terminal_token, token, consumer_id and card or customer fields are never copied. A pasted notification is never treated as verified.
• APM and wallet transaction types (including eZeeWallet payments processed through Genesis) are analyzed by their Genesis structure, but their transaction_type names are not in the research, so they are shown as unknown transaction types with stage other while their documented status is kept.
• Gateway error codes are decoded from the 93 codes of the API reference. Six codes found only in the PHP SDK and 16 issuer codes found only in the SDK are decoded with possible confidence; other three-digit codes fall back to their documented range group with possible confidence, and anything else is reported with insufficient confidence. Message text varies per acquirer; only the code classes are stable.
• Scheme response codes where the Visa and Mastercard tables differ are shown with both meanings and possible confidence, because no documented field identifies the card brand. response_code is acquirer-specific and its meaning is not documented, so it is shown but not decoded.
• Recurring advice codes override the retry guidance of a decline; PandaPayLens never suggests a retry against the issuer's advice. AVS single-character codes and most two-character result letters are recognized but not explained, because the research does not give their individual meanings.
• WPF notification error field names are not given in the research, so WPF notifications are not decoded for errors; wpf_status is kept. APM external event notifications are recognized but not analyzed, because their category and code values are not documented.
• Refund, void and capture responses do not echo the parent transaction id. Events are linked by unique_id, reference_transaction_unique_id, wpf_unique_id and payment_transaction_unique_id only; transaction_id and order_id are merchant references and are never used for correlation.
• Dispute notifications (chargeback, representment, retrieval request, RDR) are opt-in per merchant; a dispute event does not show the dispute's final outcome. The state names chargeback_reversed and chargeback_reversal (WPF) are both accepted. Managed Recurring subscriptions are out of scope, so no subscription reference is set.
• A successful capture means Genesis processed it, not that funds were settled; settlement is not reported in these payloads.

Examples

• emerchantpay: recurring sale declined: A form-encoded Genesis notification for a failed rebill; recurring advice codes decide the retry guidance.
• emerchantpay: chargeback notification: A chargeback event linked to the original transaction by its unique id.

Provider documentation

• Genesis API reference (version 61.1)
• Genesis API reference: Errors
• Genesis API reference: Scheme Response Codes
• Genesis API reference: Notifications
• Genesis API reference: Transaction States
• emerchantpay docs portal
• Server-to-server integration
• Refund
• Void
• Genesis PHP SDK: Errors.php
• Genesis PHP SDK: Notification.php

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