Rapyd

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

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by webhook id (wh_...), which a resent webhook keeps; Rapyd documents that notifications can be delivered more than once.
• Delivery order: not guaranteed by the provider.
• Rapyd delivers webhooks at least once and may deliver them out of order. Make the handler idempotent on the webhook id, compare the object status with the one already stored, and retrieve the payment, refund or payout before acting on an older state.

Known limitations

• Error codes are decoded by the field that carries them: string codes from status.error_code, status.response_code, the payment error_code and the payout error; card network codes from the ERROR_PROCESSING_CARD - [NN] suffix (with the payment failure_code as a fallback); merchant advice codes only from merchant_advice_code. A failure_code without ERROR_PROCESSING_CARD is read as a network code with possible confidence, because Rapyd also uses failure_code for bank transfer reasons and sandbox codes. A bare number in error_code is not decoded.
• Rapyd documents error_code and response_code as the same value, but one sample differs. When they differ, both are decoded with possible confidence.
• Codes that Rapyd lists more than once with different meanings (ERROR_CREATE_PAYMENT_FOR_REAUTHORIZATION, network code 76, network codes 81 and 82 with a Mastercard row) show every meaning with possible confidence. Network codes 00, 08 and 11 (Success) and 10 (Partial approval) are listed by Rapyd as errors and are shown for manual review.
• Nine codes appear only in documentation samples and are decoded with possible confidence. Sandbox simulation codes are marked as such; Rapyd notes that sandbox and production codes can differ.
• The payout field gc_error_code is documented as reserved, although Rapyd's samples put the real error there and leave error empty. Codes from gc_error_code are decoded with possible confidence at most, and only when the payout failed.
• Refund failure_code values and payment cancel_reason values are not documented and are shown without interpretation. Refund failure_reason values are interpreted with possible confidence.
• Webhook samples come in four shapes (body only, HTTP client wrapper, internal delivery record, Retrieve Webhook response) and many are not valid JSON. All four shapes are accepted when they carry the wh_ webhook id (id, or token in a delivery record); JSON with trailing commas or comments is read with a warning, other syntax errors are not repaired.
• Webhook retry schedule, retry count and acknowledgement rules are not documented on the webhook pages. At-least-once delivery and possible out-of-order delivery are stated only in Rapyd's documentation index (llms.txt).
• PAYMENT_SUCCEEDED is sent when a payment request is received; the outcome is taken from the payment status and next_action, so a 3DS payment in ACT is shown as pending. Settlement to the merchant is not a payment status and is not shown.
• A payment in ACT with next_action pending_capture is shown as an authorization; capture is shown only from PAYMENT_CAPTURED. A REST response to Capture Payment cannot be told apart from other payment responses, because the response does not name the operation.
• Payment, refund, dispute and payout events are linked only through explicit identifiers: the payment id, the refund's payment, the dispute's original_transaction_id and the payout id. operation_id and trigger_operation_id are shown and used to match an API error with its webhook, but not to group events, because Rapyd does not document whether one operation can trigger webhooks for several objects. merchant_reference_id is never used to link events.
• A refund reported by both its REST response and its webhook appears as two refund events. Payouts have no parent payment.
• Dispute amounts, scheme reason codes and dispute timestamps are not documented as fields and are not read.
• Wallet transfers between Rapyd Wallets (transfer responses and wallet transaction webhooks) are recognized but not analyzed; they are a separate lifecycle from payments and payouts. Wallet transaction error codes are still decoded when they appear in an error response.
• Dated API versions (api_version header) can change responses and webhooks, and payloads do not show the version. Partner API, Issuing, Verify, subscriptions and point-of-sale formats are not analyzed. Bare data objects without the status object or the webhook body are not recognized.
• Webhook signatures and the salt, timestamp and access_key headers are never verified or copied; a pasted webhook is never treated as authentic. Only the presence of a signature header is reported.
• Category and retry guidance per code are PandaPayLens suggestions; Rapyd's corrective actions are reflected where they decide the retry class.

Examples

• Rapyd: payment failed webhook: A card decline that requires 3DS, with a merchant advice code.
• Rapyd: payout returned: A payout created, completed and then returned, kept separate from payments.

Provider documentation

• Error messages (status object)
• Rapyd error codes
• Card network errors
• Merchant advice codes
• Create Payment
• Refund
• Create Payout
• Retrieve Dispute
• Webhook format
• Retrieve Webhook (delivery status and attempts)
• Payment webhooks
• Refund webhooks
• Dispute webhooks
• Payout webhooks
• Idempotency
• Simulated errors

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