Inpay

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

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by X-Request-ID header (webhook bodies carry no event id); Inpay documents that notifications can be delivered more than once.
• Delivery order: not documented by the provider.
• Inpay redelivers the same state with the same X-Request-ID and asks for a 200 answer to duplicates. Keep the X-Request-ID of processed webhooks, answer repeats with 200, and base state changes on the payout or order state rather than on arrival order.

Known limitations

• Merchants on the PKCS#7 security model receive signed and encrypted response and webhook bodies. Only bodies that were already decrypted (or JWT-model plain JSON) can be analyzed; an encrypted body is not recognized.
• Webhooks carry no event name and no event id; the state of the resource says what happened. Repeated deliveries are recognized only when the webhook is pasted as an HTTP request with its X-Request-ID header; a bare body has no documented duplicate key, so no deliveryKey is set.
• Webhook signatures (PKCS#7 signature, JWT in the Authorization header) are sensitive and never verified or copied; a pasted webhook is never treated as authentic. Whether the JWT model also covers Collections webhooks is not documented.
• The webhook retry schedule, retry count and delivery order are not documented. Inpay documents only that 2XX acknowledges, 3XX and 4XX stop further attempts and 5XX triggers a retry.
• Payout timestamps have no documented time zone and order webhooks have no timestamp at all, so Inpay events are not placed on the timeline by time and are ordered by input order. The payout timestamp is shown as an attribute.
• Payout completed means accepted by the banking layer or processing partner, not confirmed credit to the beneficiary; returned can follow. A payout request (received) is not a completed payout, and a bank transfer pay-in attempt is not a received payment.
• Pay-in reasons in status_reasons are free text without codes, and Inpay's example texts do not match its reason table. Only two texts that clearly name a table row are matched, with possible confidence; other texts are shown as provider messages and the documented candidate reasons for the order status are listed.
• Payment attempt changes do not trigger webhooks. Docs tables write attempt statuses in capitals with spaces (BANK AUTHORISED) while JSON examples show only created, bank_authorised, completed and consent_required; other lower snake case values are matched to the table labels and flagged as inferred. Swish and BLIK attempt statuses are not documented and stay unknown.
• The nested refund status list is not documented (examples show created, processing and completed); other values stay unknown. The meaning of the order status returned is not described, so its outcome stays unknown.
• Three different error body shapes are documented. The generic { errors: [{ title, detail }] } and { error: { details } } shapes are recognized with high confidence only when they carry a documented numeric code, a JWT error code or an Inpay field name; otherwise select Inpay manually. The response field that carries JWT error codes is not documented, so the code is accepted from any documented error field.
• Codes outside the reason table appear in Inpay examples (beneficiary-account-not-existing, validation_schema_failed, awaiting_extended_kyc). They are decoded with possible confidence and an unknown category. The reason table's kind column (refund_cancelled / refund_returned) is docs metadata; the payout state tells a cancelled row from a returned one.
• ISO 20022 status reports (pain.002 CstmrPmtStsRpt, pacs.002 FIToFIPmtStsRpt) are a generic standard: the format itself does not prove the sender is Inpay. A report is detected with confidence below 0.5, so it is analyzed only when Inpay is selected manually, unless GrpHdr/InitgPty/Nm is Inpay as in Inpay's examples. That name is plain text anyone can write, so check where the report came from.
• Only the four documented ISO 20022 group statuses (RCVD, PDNG, ACCP, RJCT) are decoded; ACCP means the checks passed, not that the payouts were sent. Other group statuses, and payment information and transaction statuses (PmtInfSts, TxSts), are not documented by Inpay and stay unknown. Inpay publishes no ISO reason code list: NARR and the text SyntaxError are decoded from its rejected example with possible confidence, other reason codes stay unknown.
• ISO 20022 reports are linked only by OrgnlMsgId, the id of the original message; GrpHdr/MsgId is kept as the report's own id. Inpay documents no per-transaction identifiers in its reports, so OrgnlEndToEndId is not used and reports are never linked to JSON payouts by end_to_end_id. CreDtTm is placed on the timeline only with a time zone; Inpay's pain.002 example uses a non-ISO date (28/06/2021 15:24).
• The ISO 20022 requests (pain.001, pacs.008), Reconciliation, FX, Account Funding, Authentication check and Sandbox APIs are not analyzed.
• The payout currency example in the OpenAPI file is the literal text ISO 4217 and the descriptions of debtor_account.id and scheme_name are swapped there. Amounts are converted only with a valid three-letter currency. The virtual account number (debtor_account.id), payer and beneficiary names, account numbers, bank identifiers and redirect URLs are never copied.
• Order reference is unique only per business unit and is not used to link events. Payouts are linked by inpay_unique_reference and end_to_end_id, which Inpay documents as the merchant's unique payout reference; orders by uuid, primary_payment, payments[].inpay_unique_reference and refund uuid.
• Inpay documents no chargebacks (bank transfer rails), no subscriptions and no card payments; none is shown. Never read a pay-in or payout state as a card authorization or capture.
• Category and retry guidance per code are PandaPayLens suggestions; Inpay gives no per-code retry advice. HTTP 500 and 503 leave the outcome of the request open and are shown as conditional retries after a status lookup.
• Sector eligibility depends on jurisdiction, licensing and Inpay's onboarding and compliance review. Account-specific product lists, per-product payout schemas and production hosts need a customer login and were not reviewed.

Examples

• Inpay: payout rejected: A payout webhook rejected for a wrong account number, with the request id used to detect repeated deliveries.
• Inpay: pay-by-bank order cancelled: An open banking payment cancelled by the payer.

Provider documentation

• Payouts introduction (payment request states)
• Payout reason codes
• Payout webhooks
• Collections order lifecycle
• Instant Bank Transfer payment status
• Collections webhooks
• Pay-in reason codes
• API errors
• HTTP response codes
• JWT signing errors
• Security models (PKCS#7 and JWT)
• X-Request-ID header
• ISO 20022 status codes
• ISO 20022 introduction

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