Trust Payments

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

Capabilities

Error decoding	supported
API response parsing	supported
Webhook / notification parsing	limited
Timeline	limited
Event correlation	supported
Diagnostic rules	limited

Supported input

Format	Description	Status
`trust_payments.webservices.envelope`	Webservices API JSON response envelope (requestreference, version 1.00, response[] or the client library's responses[], secrand), including TRANSACTIONQUERY records	supported
`trust_payments.jwt.payload`	Decoded response JWT payload of the JavaScript Library and mobile SDKs ({ iat, payload: { response[] }, aud })	supported
`trust_payments.response.object`	A single Webservices response object copied out of the response array	supported
`trust_payments.url_notification`	URL notification (form-encoded, merchant-configurable fields, notificationreference always present)	limited
`trust_payments.payment_pages.redirect`	Payment Pages browser redirect fields (errorcode, settlestatus, transactionreference; transport not documented)	limited
`trust_payments.webservices.request`	Webservices API JSON request envelope ({ alias, version, request[] })	unsupported
`trust_payments.webservices.xml`	Webservices API XML responseblock (version 3.67)	unsupported
`trust_payments.reports.csv`	Transaction and report CSV downloads	unsupported
`trust_payments.chargebacks`	Chargebacks (Portal and RAM Tool exports only; no API payload)	unsupported

Notification delivery

Repeated deliveries are recognized by notificationreference; Trust Payments documents that notifications can be delivered more than once.
Delivery order: not documented by the provider.
Process each notificationreference once and answer HTTP 200 within 8 seconds. Offline and failover notifications are resent with the same notificationreference for about 48 hours.

Known limitations

Trust Payments publishes no table for acquirerresponsecode, acquirerresponsemessage or schemeresponsecode (they vary by acquiring bank), so the reason behind a 70000 decline is never decoded and 70000 is shown with possible confidence.
Error code 50000 has two documented descriptions ("Socket receive error" in the error list, "Timeout" in the JSON Web Token article); both are shown and the outcome is treated as unknown.
Codes 60100 to 60120 share the message "Invalid process" and Portal codes 21000 to 21060 have only suggested categories; they are decoded with possible confidence. Codes not on the official list are reported with insufficient confidence.
URL notifications have no event-type field and their field set is configured by the merchant; only notificationreference is guaranteed. The event is inferred from requesttypedescription, errorcode, settlestatus and accounttypedescription when present and is marked as inferred. Without requesttypedescription the event type is unknown.
Notifications and redirects are never treated as verified: responsesitesecurity (and any other hash or JWT) is not checked, copied or reported; only whether a 64-hex value is present is shown.
The delivery key is notificationreference, which Trust Payments keeps across redeliveries. Webservices responses and Payment Pages redirects have no delivery key. Notification order and notification timestamps are not documented.
transactionstartedtimestamp and settledtimestamp have no documented time zone. They are read as UTC for ordering only, so times may be offset by the account's time zone.
Events are linked only by transactionreference and parenttransactionreference. orderreference, requestreference and subscriptionnumber are never used for correlation. Notifications carry parenttransactionreference only when the merchant configured it, and the link between a Subscription Engine schedule and the AUTHs it creates is not documented, so engine rebills may form separate groups.
Settle status 100 (Settled) means batched and sent to the acquirer, not that funds reached the merchant. Settle status 2 (Suspended) is shown as pending; the reason for a suspension is not in the payload.
Payouts are REFUND requests on a CFT account and are shown with stage payout; other REFUNDs are refunds. Mastercard duplicate-payout advice codes are shown as advice only.
Chargebacks are only available in Portal and the RAM Tool (CSV/XLSX exports); no chargeback payload exists in the gateway API or notifications, so disputes are not analyzed.
XML responseblocks cannot be analyzed because PandaPayLens input parsing accepts JSON and form data only. Encoded JWT strings must be decoded before pasting; the decoded payload is supported. Webservices request envelopes are recognized but not analyzed.
Only JSON API version 1.00 is documented; envelopes declaring another version are recognized but not analyzed.
Real payloads may contain the legacy Secure Trading names and hosts; detection is structural and never relies on brand strings.
Protect Plus fraudcontrolresponsecode values and the customeroutput field have no published meaning and are shown without interpretation.

Examples

Trust Payments: AUTH declined: A Webservices JSON response with errorcode 70000; the acquirer reason is not published, and the explanation says so.
Trust Payments: recurring payments: An initial AUTH and RECUR rebills linked by parenttransactionreference.
Trust Payments: gaming payout: A payout to a card, kept separate from deposits.

Provider documentation

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