MiFinity

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

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by none documented (MiFinity documents no callback event id).
• Delivery order: not documented by the provider.
• MiFinity documents no event id, retry schedule or duplicate rule for callbacks, so repeated deliveries cannot be recognized. A successful payout sends two callbacks (Submitted, then Processed by acquirer). Make the handler idempotent on traceId and transactionStatus, and confirm the state with the Transaction Status or Payment Status API.

Known limitations

• MiFinity documents no merchant sectors: no sector is documented on any page reviewed, so the sector list is empty. The payout callback value paymentCategoryType GAMING_PAYOUT is a payload value, not a statement of accepted sectors. Eligibility depends on jurisdiction, licensing and underwriting.
• Callbacks carry no documented signature or event id. A pasted callback is never verified and is not treated as authentic; X-MiFinity-Signature signs merchant requests to MiFinity, not callbacks, and is never copied. No deliveryKey is set, so repeated deliveries are not recognized as duplicates.
• Payout status 5 contradicts itself: most pages document it as Processed by acquirer (final success), the withdrawal callbacks page as Failed. Both meanings are shown. The outcome follows transactionStatusDescription when present; without it the outcome stays unknown.
• Status 4 (Processed by PSP) appears only on the older transaction status page. Reversed has no numeric id and is recognized only by transactionStatusDescription. No parent or original transaction field is documented for reversals.
• Submitted (3) means the funds are debited and MiFinity says to treat it as success, but Processed by acquirer, Rejected or Internal Error can follow; it is shown as pending.
• TRANSACTION_FAILED is a catch-all for unrelated causes and can carry processor text. It is decoded with possible confidence and an unknown category; the message gives only a hint.
• The PayAnyCoin (crypto payout) error reference is not published (the PAYC Gateway Error Reference and Runbook are named but not available), and only statusCode 7 / PENDING is documented. Other PayAnyCoin statuses stay unknown; statusCode 7 is never read as transactionStatus 7.
• Deposit callbacks have no status field on success and no timestamps. Success is inferred from the absence of errorMessage and detailedStatus and must be confirmed with the Payment Status API. The Refused by Risk example carries the same errorMessage as an abandoned deposit, so detailedStatus decides.
• Refunds, chargebacks, cancellations, subscriptions and deposit reversals are not documented and are not shown.
• traceId is merchant supplied. It links payout events only, where MiFinity rejects a reused traceId (DUPLICATED_TRANSACTION_ID). Deposit events are linked only by transactionReference; the content of the Payment Status paymentResponse object is not documented and is read with the deposit callback field names.
• createdOn is the creation time of the payout, not of the status change. It is used as event time only when transactionLastUpdated is missing.
• Error messages often contain unfilled placeholders ({0}), and the same code can appear under different error types. The generic list of 56 HTTP status codes has no MiFinity specific meaning; only 401 (Account to Account with TOTP), 403, 404 on status lookups and 5xx have documented rules.
• Money objects differ by endpoint (presentationAmount, displayable, actual), the fee field is totalFee in tables and totalFees in examples, and exchangeRate is a number or an object. Amounts are read from amount and currency only.
• The init-iframe response is recognized but not analyzed (it carries a session token, not a payment result). Lookup endpoints (currencies, bank fields, account listing) are not analyzed. Callback fields without a documented meaning, such as externalReference and responseCode, are not used.
• Category and retry guidance per code are PandaPayLens suggestions; MiFinity gives no per-code retry advice except the duplicate traceId rule and the status lookup rules.

Examples

• MiFinity: payout flow: A wallet payout from submission to its final status.
• MiFinity: deposit refused by risk: A wallet deposit callback refused by the risk check.

Provider documentation

• Error codes
• PAB error codes
• Transaction status (payout status ids, 404 and 5xx handling)
• Transaction status (older table with status 4 and Reversed)
• Notification callbacks (payouts)
• Notification callbacks for withdrawals (documents status 5 as Failed)
• Payment status callback (deposits)
• Payment Status API (deposits)
• PayAnyBank flow (traceId retries)
• PayAnyCoin API
• Merchant signature verification (requests to MiFinity only)

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