{"service":"infinihash-baas","settlementAdapter":"bridge","capabilities":{"invoicing":{"available":true,"endpoint":"POST /api/v1/invoices"},"ach_collection":{"available":true,"endpoint":"POST /api/v1/invoices/{id}/pay"},"stablecoin_settlement":{"available":true},"kyt_screening":{"available":true},"managed_escrow":{"available":false,"reason":"the settlement rail in force (\"bridge\") cannot custody escrowed value — it forwards funds to the destination wallet as a single transfer, so an escrow funded through it would report as held while the money had already left. Escrow endpoints exist and validate, but funding is refused at the door rather than bricking a funded escrow.","code":"escrow_hold_unsupported","status":409,"endpoint":"POST /api/v1/escrow/{id}/fund","docs":"https://rails-api.infinihash.com/api/docs#hold-managed-escrow"},"refunds":{"available":false,"reason":"no settlement adapter on this deployment implements a refund leg (\"bridge\" declares no refund capability). Dispute rules that would auto-refund are routed to human review instead of recording a refund no rail performed.","code":"refund_unsupported","status":409},"disputes":{"available":true,"reason":"queue, evidence handling and rules are live; no third-party alert vendor (ethoca, verifi_cdrn, verifi_rdr) is contracted, so nothing populates the queue automatically — alerts arrive only via the sources we own (mock, manual, network, acquirer), which are hand-entered or partner files we load ourselves; refund outcomes are unsupported on this deployment and route to human review","endpoint":"GET /api/v1/disputes/queue","docs":"https://rails-api.infinihash.com/api/docs#disputes"},"self_serve_onboarding":{"available":true,"endpoint":"POST /onboard/signup"}},"ts":"2026-09-13T02:46:10.911Z"}