AstroPay
Adapter 0.1.0, documentation reviewed 2026-10-25. Overall status: limited.
Capabilities
| Error decoding | limited |
| API response parsing | supported |
| Webhook / notification parsing | limited |
| Timeline | limited |
| Event correlation | limited |
| Diagnostic rules | limited |
Supported input
| Format | Description | Status |
|---|---|---|
astropay.checkout.create_response | Checkout create payment response (POST /v1/payments: payment_external_id, status) | supported |
astropay.checkout.callback | Checkout callback (payment_external_id, payment_status, payment_info.payment_amount); RSA Partner-Signature | limited |
astropay.checkout.payment | Payment object with a Checkout-only status (EXPIRED), with payment_transactions steps | supported |
astropay.wof.payment | Wallet on File payment object with a Wallet on File-only status (AUTHORIZED, CAPTURED, REVERSED and partial variants) | supported |
astropay.payment_object | Checkout or Wallet on File payment object whose family is not visible; only statuses both families document identically are interpreted | limited |
astropay.cashout_v1 | Wallet Payouts / Cashouts V1 response and callback (cashout_id, merchant_cashout_id, status); HMAC Signature header | supported |
astropay.direct_payment | Direct Payment response and callback (deposit_external_id, merchant_deposit_id, status) | supported |
astropay.direct_withdrawal | Direct Withdrawal response and callback (cashout_external_id, merchant_cashout_id, status, cancel reason in description) | supported |
astropay.qr.callback | QR Payments deposit callback (deposit_external_id, payment_code_external_id, amount, status); HMAC Signature header | limited |
astropay.merchant_gateway.error | OneTouch / merchant-api error envelope (error, description, internal_term, reasons, detail) of Direct Payment, Direct Withdrawal and QR Payments | supported |
astropay.partner.error | Checkout and Wallet on File error body (error plus message or description): refund, auth-capture and account linking tables | limited |
astropay.cashout_v1.error | Cashouts V1 error, which has no machine code; decoded from the documented description text and HTTP status only | limited |
astropay.wallet_deposit | Classic wallet Deposit API (OneTouch deposit) callback with deposit_user_id: its documentation is in a private section that was not read (recognized but not analyzed) | unsupported |
astropay.platform.error | Platform (Partners API, BaaS) error codes (out of first scope; recognized but not analyzed) | unsupported |
astropay.platform.webhook | Platform webhooks sent to {baseWebhookUrl}/{eventName} (out of first scope; recognized but not analyzed) | unsupported |
Notification delivery
- Repeated deliveries are recognized by product family, AstroPay identifier and status (merchant callbacks carry no event or delivery id); AstroPay documents that notifications can be delivered more than once.
- Delivery order: not documented by the provider.
- AstroPay retries callbacks (Checkout until acknowledged, Direct Payment up to 4 more attempts) and sends no event id. Treat a callback with the same AstroPay identifier and status as a repeat, answer 200 OK, and make the handler idempotent on that identifier. A Brazil Direct Payment can move from CANCELLED to APPROVED, so a later status must still be processed.
Known limitations
- The classic wallet Deposit API (OneTouch deposit with merchant_deposit_id and deposit_user_id) is documented only in unlisted /docs/private/ sections that were not read. It is not implemented. Callbacks with deposit_user_id are recognized but not analyzed; a classic deposit callback without that field shares Direct Payment field names and would be read with Direct Payment semantics.
- AstroPay's developer site is client-rendered, and the research rebuilt its tables from the site's public content bundles, so a value can sit in the wrong cell. Confidence is kept modest: strong only when a code matches exactly and a second documented column agrees (the HTTP status, or the final CANCELLED status for cancel reasons); otherwise possible.
- Cashouts V1 errors have no machine code. They are matched on documented key words in the description text and on the HTTP status, from paraphrased descriptions, with possible confidence at most. Texts that match no row stay unknown.
- Checkout and Wallet on File reuse some error codes with different meanings per operation (refund, auth-capture, account linking). The operation is not in the error body; the HTTP status narrows it where the tables differ, and otherwise every documented meaning is shown with possible confidence.
- AstroPay runs several product families with their own identifiers, statuses and signature schemes. Each family has its own format and status table and they are never mixed. Checkout and Wallet on File share one payment object: the family is taken from a status only one of them documents; for shared statuses only meanings both families document identically are used.
- The Platform API (Partners API, BaaS) is out of first scope: Platform-only error codes and webhooks sent to {baseWebhookUrl}/{eventName} with Partner signature headers are recognized but not analyzed. Generic codes that the Platform shares with other APIs are not used for recognition.
- Merchant callbacks carry no event or delivery id. Repeated deliveries are recognized by product family, AstroPay identifier and status. end_status_date is not part of the key because its meaning differs between pages (status change time for Cashouts, callback send time for QR).
- end_status_date is documented without a time zone, so it is shown as an attribute and not placed on the timeline; values that carry a zone are used. The payment object has no per-step timestamps and delivery order is not documented, so most AstroPay events are ordered by input order.
- In Brazil a Direct Payment in CANCELLED is not final and can become APPROVED after 30 minutes. The callback does not name the country, so every Direct Payment CANCELLED is shown as a failure flagged as possibly not final.
- The full Direct Payment status list is not documented; Direct Withdrawal CREATED appears only in a create example; a QR create example returns ACTIVE although the field is typed PENDING, APPROVED or CANCELLED. Undocumented statuses stay unknown.
- The payment object amount fields carry no documented currency, so they are not converted. Cashouts V1, Direct Payment and Direct Withdrawal responses and callbacks carry no documented amount. Only Checkout callbacks (payment_info.payment_amount) and QR callbacks show amounts.
- Signatures (HMAC Signature header, RSA Partner-Signature header) are sensitive and never verified; a pasted callback is not treated as authentic. Only the presence of a signature header is shown. Direct Payment and Direct Withdrawal callback signing is not stated on their callback pages.
- Wallet on File webhooks are documented without a payload or signature format and are not recognized. Checkout refund callbacks are sent if configured but their payload is not documented.
- AstroPay documents no chargeback, dispute or settlement events in any public family. Chargebacks cannot be shown on the timeline.
- AstroPay describes its error lists as the most common ones; other codes stay unknown. Category and retry per code are PandaPayLens suggestions, with AstroPay's own advice reflected where it gives one. A payment creation timeout, which AstroPay says to try again, is shown as a conditional retry because the original outcome is unknown.
- Merchant references (merchant_payment_id, merchant_deposit_id, merchant_cashout_id) are never used to link events, and user identifiers (merchant_user_id, user_id, cashout_user_id, deposit_user_id) are not copied. No identifier links one family to another.
- The approved Direct Withdrawal description (for example SPCD_1000) has no documented code space; it is shown as text only. Payment transaction results drift between OK/FAILED and APPROVED, and is_reversable/is_reversible are both read.
- QR Payments: only the deposit callback is analyzed; payment code creation and status, the POS API and user onboarding are not. The older Direct API ('AstroPay Direct has changed!') and the /api reference page were not examined and are not supported.
- Orchestration and card processing are not claimed as categories because AstroPay's role there is unclear. Sector eligibility depends on jurisdiction, licensing and underwriting; 'Gaming' is AstroPay's word and is not documented as including or excluding any specific gambling vertical.
Examples
- AstroPay: withdrawal cancelled: A payout cancelled with a documented cancel reason.
- AstroPay: payment creation timeout: An HTTP 408 timeout: the outcome is unknown, so the payment must be checked before any retry.
Provider documentation
- Checkout callback and statuses
- Checkout payment status
- Checkout refunds and refund errors
- Wallet on File funds pulling
- Wallet on File errors
- Cashouts V1 getting started (statuses)
- Cashouts V1 callbacks
- Cashouts V1 error codes
- Direct Payment callbacks
- Direct Payment error codes
- Direct Payment Brazil (PIX, CANCELLED not final)
- Direct Withdrawal callbacks
- Direct Withdrawal cancel reasons
- QR Payments callbacks
- QR Payments security and authentication
- Platform error codes (out of scope)
PandaPayLens is not affiliated with AstroPay. Pasted notifications are never treated as verified: PandaPayLens does not check webhook signatures.