Paymentwall

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

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by ref and type (the SDK's unique pingback id ref_type, also available as the UNIQUE_REF custom parameter); pingbacks carry no event id; Paymentwall documents that notifications can be delivered more than once.
• Delivery order: not documented by the provider.
• Store each ref (with its type) and refuse a repeated ref for type 0, then answer HTTP 200 with body OK. Until the OK arrives, Paymentwall resends the pingback within 30 minutes and then every 30 minutes.

Known limitations

• Pingbacks arrive as an HTTP request with the data in the URL query string. Paste the raw request, the full URL or just the query string; the host and path are not used for detection.
• Pingbacks carry no timestamp and no event id. Events from pingbacks have no event time and their order is the order of the supplied records. Delivery keys use the SDK's documented unique id (ref and type); partial refunds (type 220) and partial reversals (type 2, reason 10) can repeat for one ref, so they have no delivery key.
• Custom pingback parameters (REFERENCE_ID, UNIQUE_REF, PAYMENT_DATETIME, REVENUE, SUBSCRIPTION_ID, RECURRING_*, CHARGEBACK_* and OWN parameters) are sent under merchant-chosen names and are not read. Amounts, currencies, payment times and subscription ids from pingbacks are therefore not shown.
• Pingback type 1 is documented inconsistently (Virtual Currency payment confirmation in the Test Pingback Tool, GOODWILL in the PHP SDK, absent from the main pingback page). Type 220 is not among the SDK constants. In Virtual Currency pingbacks, currency is the amount of virtual currency, not an ISO currency.
• A pingback does not say whether a type 0 payment is the first charge of a subscription or a renewal, so isRecurring is set only for type 14 (renewal failed). Types 12, 13 and 14 are sent only when activated for the project.
• A negative pingback with reason 1 (chargeback) is shown as a dispute with unknown outcome; the payload does not say whether the chargeback is final.
• The relation between the Brick charge id (numeric) and the pingback ref (b..., t..., w... prefixes, meaning not documented) is not documented, so Brick API objects and pingbacks are not linked. Mobiamo refs are kept in their own namespace for the same reason.
• Code spaces collide: Brick and MINT redemption reuse 1001, 1003, 3001 to 3006, 3008 and 3009 with different meanings, and 200 is both a Brick token error and a pingback type. Codes are decoded by the product family the payload structure shows (Brick error JSON, SDK envelope, Mobiamo W codes). When the structure does not show the family, every documented meaning is listed with possible confidence.
• The MINT error envelope is not documented; MINT codes are decoded only from an unidentified error shape { code, error | message } when Paymentwall is selected manually, always with possible confidence.
• The PHP SDK error envelope { success: 0, error: { message, code } } wraps Brick responses; whether the raw API also returns success is unclear. It is decoded with the Brick tables.
• Brick charge risk values beyond approved are not documented (pending appears only in the PHP SDK). A voided charge is not distinguished from an uncaptured authorization because no void flag is documented. Charge and subscription date fields are not read because their format is not documented.
• Brick internal errors (1000) and MINT redemption internal errors (1001) are shown as retry after verification, not as safe to retry, because the original operation may have taken effect.
• Signatures (sig, v2 MD5 or v3 SHA-256) are never verified or copied; only their presence and length class are shown. A pasted pingback is never treated as authentic. The documentation reuses one placeholder sig value across samples.
• uid (which defaults to the e-mail for Brick), tokens, fingerprints, 3-D Secure redirect URLs and form HTML, support_link, card data, customer names and addresses, MSISDN and IP addresses are never copied.
• Client-side postMessage events are recognized but not analyzed (they come from the browser and are not authoritative). Payment Status API, Widget and Checkout URLs, Cancellation, Delivery Confirmation, Tokidoki, Reporting and Coupon APIs are not analyzed. Widget errors have no codes. Payouts and wallet transfers are not documented.
• Merchant Area content (Test Pingback Tool output, project settings) needs a login and was not examined. The Terminal3 documentation (Paymentwall's spin-out, same formats) was used only to confirm the Brick code list; Terminal3 payloads cannot be told apart and are treated as Paymentwall.
• Brick minimum amount is inconsistent in the documentation (charge reference USD 0.3, error 3115 default 0.50 USD).

Examples

• Paymentwall: subscription renewal failed: A type 14 pingback: a recurring charge failed.
• Paymentwall: Brick payment declined: A Brick error decoded from the Brick code table.

Provider documentation

• Pingback reference
• Test Pingback Tool (pingback type table incl. type 1)
• Signature calculation (v2 MD5, v3 SHA-256)
• Custom pingback parameters
• Brick error codes
• Brick charge
• Brick 3-D Secure
• Brick subscription
• Brick pingback handling
• API reference (Brick objects, Mobiamo, MINT)
• Client-side callback
• Terminal3 Brick error codes (Terminal3 is Paymentwall's spin-out; used only to confirm the Brick code list)
• paymentwall-php Pingback.php (type constants, unique id ref_type)

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