Skrill

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

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by mb_transaction_id and status (Skrill documents no event id); Skrill documents that notifications can be delivered more than once.
• Delivery order: not documented by the provider.
• Skrill posts again until it receives HTTP 200 (up to 10 posts) and warns about repeated posts for the same transaction. Make the status_url handler idempotent per mb_transaction_id and status, and answer HTTP 200.

Known limitations

• Skrill publishes no raw Quick Checkout status_url example, and the Content-Type of the post is not documented. The adapter follows the documented field tables and accepts the fields as a form body, a raw HTTP request, a URL query string or a JSON dump of the fields.
• Quick Checkout payout and bank payout status posts use the same field set as payment posts and cannot be told apart from them by structure. A post is marked as a payment only when it carries a field documented only for payments (for example customer_id, payment_type WLT/MDB, rec_payment_id); otherwise it is shown with stage payment and operation payment_or_payout. Status 1 (scheduled) and -4 (returned) occur only in bank payout posts and are shown as payouts.
• failed_reason_code is sent only with status -2 and only when Skrill Merchant Services has enabled it. A failed post without it is decoded only as failed; PandaPayLens does not guess the reason. Code 54 is cited in the status -2 description but is in neither reason-code table and is decoded with possible confidence.
• The Quick Checkout and Wallet Checkout reason-code tables disagree: code 19 means invalid or expired credentials in one and 'retry transaction' in the other, and code 06 is worded differently. Both meanings are shown. Padded (05) and unpadded (5) values are treated as the same code. Reason codes in bank payout posts are not decoded, because no table is documented for them.
• Refunds, chargebacks and payouts get a new mb_transaction_id, and no notification field links them to the original payment. They are never merged with the payment by amount, time or merchant reference. Which ids a chargeback (-3) post carries is not documented.
• transaction_id is a merchant reference (in refund reports it is the refund transaction ID) and is never used for correlation. mb_transaction_id and rec_payment_id (recurring / 1-Tap mandate) are the only correlation keys.
• Posts carry no timestamp and no event id. Repeated deliveries are recognized by mb_transaction_id and status. Recurring posts have no reliable delivery key. Retry behavior for refund and recurring posts and the delivery order are not documented; events are shown in the order supplied.
• md5sig, sha2sig and msid are never verified (that needs the merchant's secret word) and never copied; only their presence and hex length are shown. A pasted post is never treated as authentic.
• XML API responses are analyzed only in the documented shapes: <response><error><error_msg>, the flat refund.pl execution response and <response><transaction>. The prepare answer (<response><sid>) is recognized but not analyzed, because it carries no outcome; the session id is never copied, and Verification of Payee results in Quick Checkout payout prepare responses are not decoded. Other roots, namespaced roots and undocumented elements are not claimed.
• An XML error response does not name the endpoint (refund.pl, pay.pl or ondemand_request.pl) or the step (prepare or execute), so the decoded error is not tied to a refund, payout or payment. A value of error_msg that is not shaped like an error code is never shown.
• pay.pl send money, Quick Checkout payouts and ondemand_request.pl 1-Tap payments answer with the same <transaction> element. Status 1 (send money) and 0 (Quick Checkout payout) identify a payout; status 2 and -2 are documented for several of these operations, so the event is shown with stage other and the possible operations, and is never counted as a payment or a payout. A transfer response with status 2 means the transfer was processed; it is not a status report.
• The refund.pl execution response is a refund, never a payment. Status 2 means the refund was processed and 0 that it is pending until the refund status report arrives (they share the refund's mb_transaction_id). The response has no field for the original payment, and echoed merchant_fields elements are never copied. A failed execution (status -2) without error_msg is shown as a failed refund without a decoded reason.
• MQI errors are documented only as HTTP status codes 401 to 405 (and the text 403 Transaction not found: TRN_ID); the body layout is not documented. A plain-text HTTP error is offered below the detection threshold and is analyzed only when Skrill is selected manually; the transaction id in the body is never copied. MQI text responses (status_rec, status_od) and history CSV are not imported, and the two Bank API codes are in the catalog only.
• The rec_status_url post is decoded only for status 2 and -2; the docs describe that URL both as a cancellation URL and as receiving every recurring payment, and its field set is partly undocumented. ondemand_status_url (1-Tap cancellation) field names are not documented and are not recognized.
• Bank payout JSON errors are documented both as flat code/message/description and as nested error.code with details. Numeric 70xx codes in the nested shape are not claimed automatically, because Paysafe JSON uses the same shape; select the provider manually. Code 7016 is not documented. Bank payout success responses are not analyzed.
• Skrill used as a payment method inside Paysafe Checkout or the Paysafe Payments API uses Paysafe's own JSON format (paymentType SKRILL). It is not recognized by this adapter.
• Skrill is a wallet: there is no authorization, capture or void model for merchants. Status 2 means the funds reached the merchant's Skrill account; it is neither a card authorization nor a bank settlement. Card issuer outcomes reach the merchant only as failed_reason_code, and who acquires cards is not documented.
• pay_from_email, pay_to_email, customer_id, country fields, IP_country, instrument_id and echoed merchant_fields values are never copied. mb_amount can carry more decimals than the currency allows; it is then not converted, and the event amount uses amount/currency.
• The return_url parameters (transaction_id, msid) only show that the customer finished the checkout and are recognized but not analyzed. The Balance Notification Webhook and Balance Exchange (treasury) are out of scope. Skrill JS browser codes and Verification of Payee results are not included.
• An MQI status_trn response has the same fields as the status_url post; pasting both for one transaction shows them as repeated deliveries.
• The web documentation carries no version or date stamps.

Examples

• Skrill: payment failed: A status_url post with status -2 and a failed_reason_code.
• Skrill: chargeback status: A status -3 post: a chargeback with no link to the original payment.

Provider documentation

• Skrill Quick Checkout guide
• Quick Checkout status_url fields and status values
• Quick Checkout failed reason codes
• Wallet Checkout failed reason codes
• Account and integration options (refunds, chargeback notification)
• Skrill recurring billing
• MD5 signature
• API error messages
• Refunds API
• Quick Checkout payouts
• Merchant Query Interface
• Unlinked merchant bank payouts

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