Finrax

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

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by depositId for deposit callbacks, withdrawalId and status for withdrawal and approval callbacks (Finrax sends no event or delivery id); Finrax documents that notifications can be delivered more than once.
• Delivery order: not documented by the provider.
• Finrax retries a callback every 2 minutes for up to 24 hours until it counts as delivered, and what counts as delivered is not documented. Credit a deposit once per depositId and act on a withdrawal status once per withdrawalId, so that a repeated callback changes nothing.

Known limitations

• Finrax documents no provider error or decline codes. Errors are decoded from the HTTP status (nine documented codes) and the free-text message only; other status codes stay unknown. Category and retry per code are PandaPayLens suggestions.
• Status values are documented without definitions. Meanings come from the sandbox table where it shows the value, otherwise from the name, and each event says which (statusBasis). PENDING versus AWAITING, payment and deposit FAILED, withdrawal FAILED and approval SKIPPED are not documented and are not interpreted beyond their names; SKIPPED stays unknown.
• An underpaid deposit has no status of its own: the sandbox shows DEPOSITED for exact and for underpaid deposits. A DEPOSITED payment or a CONFIRMED deposit is shown as a success only when the same record shows an actual amount at least equal to the expected amount; otherwise the outcome is unknown and amountCheck says why. Whether actualDisplayAmount in the deposit callback is per deposit or cumulative is not documented, so a split payment can look underpaid per callback.
• A confirmed deposit or an OVERPAID payment means funds were received on chain, not that they were settled to the merchant. No settlement event is created: the settlement amount and currency fields are shown as reported, and bank settlement in EUR, USD or GBP is mentioned on the homepage without an API.
• Crypto amounts (deposit, withdraw and refund amounts) are shown as decimal text with their coin and are never converted to minor units. Display amounts are converted only when displayCurrency is a three-letter code that is not one of the documented coins; whether displayCurrency can be a coin is not documented. Refund amounts carry no documented currency.
• Callbacks carry no event type and no event or delivery id; the callback type is taken from the payload shape. Repeated deliveries are recognized by depositId, or by withdrawalId and status. Acknowledgment rules, content type, the exact header names and the timestamp unit are not documented.
• Callbacks are signed with RSA SHA-512 over the body and a timestamp. PandaPayLens never verifies the signature and never treats a pasted callback as authentic; only the presence of a Signature header is shown.
• Payment status snapshots carry no time of their last status change, so they are placed after the timed events of the same payment. Only NEW uses paymentRequestedAt. Withdrawal and approval callbacks carry no timestamp. Delivery order is not documented.
• Withdrawal fields are spelled differently in the 201 response (withdrawId, clientWithdrawId), the 202 response (withdrawalId, clientLabel) and the callbacks (withdrawalId, clientWithdrawalId); all spellings are read. The callback schema spells deducedSettlementAmount while the example uses deductedSettlementAmount; both are read. Sandbox withdrawal statuses (SENT, ABORTED, REJECTED) differ from the API enum and stay unknown.
• The approval fetch response is only {"status": ...} and cannot be recognized from its shape. The payment list response wrapper, the metadata, rate, balance and address validation endpoints, and the request bodies are not analyzed; a create payment request is recognized but not analyzed.
• Merchant references (clientPaymentId, clientWithdrawId, clientWithdrawalId, clientLabel) are never used to link events. Blockchain addresses, destination tags, transaction hashes, payment URLs with session tokens, initiatedBy, businessId and AML screening results (riskScore, addressRiskAssessment, txAddressOwner) are never copied; only their presence is shown where it helps.
• Finrax documents no chargebacks, disputes, subscriptions or rebills; none can appear on the timeline.
• The API base URL is not public, sandbox access needs an organisation set up by Finrax support, and the documentation is a multi-brand template: payloads from other brands served by the same API cannot be told apart from Finrax.
• Sector eligibility depends on jurisdiction, licensing and Finrax underwriting, none of which is published. Finrax also says it is built for unnamed high-risk verticals; that is not a sector list. Forex appears only as an event name and is not listed as a sector.

Examples

• Finrax: underpaid crypto payment: A deposited payment where only part of the expected amount arrived; shown as an unknown outcome, not a success.
• Finrax: blocked deposit and pending refund: A blocked deposit whose refund still waits for an address.

Provider documentation

• Errors (HTTP status codes and error body)
• Request signature
• API keys and IP whitelist
• Sandbox environment and test outcomes
• Request crypto payment
• Fetch payment
• Request crypto withdrawal
• Fetch crypto withdrawal approval
• Callbacks and their signature
• Deposit received callback
• Withdrawal completed callback
• Withdrawal approved or rejected callback

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