Skip to main content

AI Payout & B2B Wallet API

Multi-Ledger Wallet Smart Settlement Routing Risk-Aware Payout Timing FX Netting Reconciliation Artifacts Idempotency + Webhooks
Operated by Spyface Tech Company, LLC • 30 N Gould St Ste N, Sheridan, WY 82801 USA • Support: hello@spyface.com

Purpose

The AI Payout & B2B Wallet API is a programmable settlement layer for complex, multi-party ecosystems (travel suppliers, agencies, OTAs, marketplaces, clinics, hospitals, facilitators). It provides: multi-ledger wallets, automated payout orchestration, FX handling, and audit-grade reconciliation artifacts.

The AI layer optimizes payout decisions across cost, speed, failure probability, compliance controls, and liquidity constraints—without turning the page into marketing language.

Decision Outputs (AI)

  • route: preferred payout rail & corridor
  • eta_bucket: expected settlement time bucket
  • p_fail: payout failure probability (calibrated)
  • expected_total_cost: fees + FX + ops + failure overhead
  • holdback: recommended reserve for dispute/chargeback windows
  • actions: split, net, schedule, retry, or manual review

1) Core Capabilities

Programmable B2B wallet

  • Multi-tenant, multi-currency wallet accounts
  • Multi-ledger separation: available, pending, reserved
  • Immutable journal entries for audit and reconciliation

Payout orchestration

  • Single & bulk payouts with rule-based splits
  • Scheduled payouts (time-based or event-based)
  • Failure-aware retries and rerouting suggestions

Settlement intelligence (AI)

  • Route selection based on cost, speed, and failure probability
  • Liquidity-aware payout timing (avoid drains, reduce failures)
  • Corridor anomaly detection (fee spikes, bank downtime patterns)

Reconciliation & audit

  • Settlement proofs + trace IDs per payout
  • Ledger → payout mapping with deterministic references
  • Exportable artifacts for ERP/finance ingestion

2) Wallet & Ledger Model

Each counterparty (supplier, clinic, partner, agency) is represented as a wallet account with distinct ledgers. The system uses double-entry principles to preserve invariants and make reconciliation deterministic.


// Ledger invariants (conceptual)
available + reserved + pending == balance_total
journal_entry: { debit_account, credit_account, amount, currency, reference }

Ledgers

  • available: funds eligible for payout
  • pending: funds awaiting confirmation/settlement (e.g., booking not consumed)
  • reserved: holdback for disputes, refunds, chargebacks, SLA penalties

3) Smart Settlement Routing (AI)

Routing selects the best payout rail/corridor for a given beneficiary, currency, and urgency. The objective is not “fastest” or “cheapest” alone; it optimizes expected total cost including failure overhead and operational rework.


expected_total_cost =
  base_fee(route)
+ fx_cost(route)
+ p_fail(route) * failure_overhead
+ ops_cost(route, beneficiary_risk)
Routing signalExampleWhy it matters
Failure probability p_fail=0.22 for corridor X at certain bank hours Avoids repeated returns and manual ops cost
Fee volatility Spike detection on route fees Prevents margin loss during corridor shocks
Beneficiary validity Account mismatch patterns Reduces avoidable payout failures
Liquidity posture Preserve minimum operational float Avoids cascading payout rejections

4) Risk-Aware Payout Timing (AI)

Timing decisions schedule payouts based on dispute windows, refund likelihood, consumption status, and counterparty reliability. This prevents “pay too early, claw back later” failure modes.

Timing inputs

  • Booking lifecycle stage (booked, ticketed, checked-in, consumed)
  • Refund probability / cancellation risk
  • Partner reliability score and historical dispute rate
  • Market events (disruption, operational spikes)

Timing outputs

  • release_policy: immediate vs scheduled release
  • holdback: recommended reserve amount
  • payout_window: recommended execution window

holdback = f(p_refund, p_chargeback, amount, partner_dispute_rate, policy_rules)
schedule = argmin_time( expected_total_cost(time) ) subject to liquidity_constraints

5) Netting, Splits, and FX

Splits

  • Multi-party distribution (supplier + agency + affiliate)
  • Percentage, fixed, or tiered splits
  • Supports fee-on-top and fee-included structures

Netting & FX

  • Net multiple payables/receivables per counterparty
  • FX netting to reduce conversion churn
  • Corridor-aware FX selection (cost vs certainty)

// Example: netting
net_payable = sum(payables) - sum(reversals) - sum(setoffs)

// Example: split instruction
splits: [
  { beneficiary_id:"supplier_01", amount: 540 },
  { beneficiary_id:"agency_19",  amount: 80  },
  { beneficiary_id:"affiliate_7",amount: 20  }
]

6) Controls: Limits, Reserves, and Compliance

Note

Compliance requirements vary by business model and jurisdiction. The API provides controls and audit artifacts, but you must configure rules consistent with your legal/compliance program.

ControlWhat it doesExample
Velocity limits Caps payout frequency/amount per partner Max $50k/day until trust level increases
Reserve policy Moves funds to reserved ledger Reserve 3% for 14 days for high-risk corridors
Sanction/blocked checks hooks Supports deterministic gating Block if beneficiary flagged by internal rules
Approval workflows Manual review requirements for edge cases Require 2-person approval over $250k

7) Endpoints

MethodEndpointPurpose
POST/v1/walletsCreate a wallet account
GET/v1/wallets/{wallet_id}Wallet state + ledgers
POST/v1/ledger/entriesPost journal entries
POST/v1/payoutsCreate payout (single)
POST/v1/payouts/bulkCreate payouts (bulk)
POST/v1/payouts/planAI route + timing recommendation
GET/v1/payouts/{payout_id}Payout status + trace
POST/v1/reconciliation/exportFinance-ready export artifacts
POST/v1/events/outcomesSend outcomes for learning/calibration

8) Schemas

Plan a payout (AI)

{
  "request_id":"req_plan_1001",
  "payout":{
    "wallet_id":"w_9012",
    "beneficiary_id":"b_771",
    "amount":6400,
    "currency":"USD",
    "urgency":"STANDARD",
    "purpose":"SUPPLIER_SETTLEMENT"
  },
  "context":{
    "product":"FLIGHT_BOOKING",
    "market":"US",
    "consumption_status":"TICKETED",
    "refund_window_days":7
  }
}

Plan response

{
  "request_id":"req_plan_1001",
  "route":{
    "rail":"BANK_TRANSFER",
    "corridor":"US->US",
    "provider_hint":"ROUTE_A"
  },
  "eta_bucket":"T+1",
  "p_fail":0.03,
  "expected_total_cost_usd":9.84,
  "holdback":{
    "amount":192,
    "currency":"USD",
    "policy":"RESERVE_3PCT_7D"
  },
  "recommended_actions":[
    {"type":"SCHEDULE", "execute_at":"2026-01-26T18:30:00Z"},
    {"type":"RESERVE", "ledger":"reserved", "amount":192}
  ],
  "reason_codes":[
    "LOW_FAILURE_CORRIDOR",
    "REFUND_WINDOW_ACTIVE",
    "PARTNER_STABLE"
  ]
}

Create payout

{
  "idempotency_key":"idem_payout_7f2c",
  "payout":{
    "wallet_id":"w_9012",
    "beneficiary_id":"b_771",
    "amount":6208,
    "currency":"USD",
    "reference":"INV-2026-00191",
    "metadata":{
      "booking_id":"bk_88219",
      "supplier_id":"sup_88"
    }
  },
  "execution":{
    "mode":"SCHEDULED",
    "execute_at":"2026-01-26T18:30:00Z"
  }
}

9) Idempotency, Webhooks, and Retries

Idempotency

  • Use Idempotency-Key for POST /v1/payouts
  • Prevents duplicate payouts on timeouts/retries
  • Idempotency window is configurable by account tier

Webhooks

  • payout.created, payout.sent, payout.failed, payout.settled
  • Signed webhook payloads (HMAC)
  • Replay protection via timestamp + nonce

// Retry guidance (conceptual)
if (http_status in [429, 503]) retry_with_exponential_backoff()
if (payout_failed && reason == "ROUTING_TEMPORARY") request_new_plan_and_reroute()

10) Code Examples

Node.js — Plan + Execute payout


const base = "https://api.spyface.com";
const headers = {
  "Authorization": `Bearer ${process.env.SPYFACE_API_KEY}`,
  "Content-Type": "application/json"
};

const planRes = await fetch(`${base}/v1/payouts/plan`, {
  method: "POST", headers, body: JSON.stringify(planPayload)
});
const plan = await planRes.json();

// Apply recommended actions (reserve/schedule) in your orchestration layer.
// Then create payout with idempotency key.
const payoutRes = await fetch(`${base}/v1/payouts`, {
  method: "POST",
  headers: { ...headers, "Idempotency-Key": "idem_payout_7f2c" },
  body: JSON.stringify(createPayoutPayload)
});
const payout = await payoutRes.json();
console.log(payout.status, payout.payout_id);

Python — Verify webhook signature (HMAC)


import hmac, hashlib

def verify(sig, ts, body, secret: bytes) -> bool:
  msg = (ts + "." + body).encode("utf-8")
  expected = hmac.new(secret, msg, hashlib.sha256).hexdigest()
  return hmac.compare_digest(sig, expected)

11) Reconciliation Artifacts

Reconciliation is deterministic when every payout and ledger movement shares stable references: reference, booking_id, journal_entry_id, and provider_trace_id.

{
  "payout_id":"po_55119",
  "status":"SETTLED",
  "provider_trace_id":"prov_9c21",
  "ledger_map":[
    {"journal_entry_id":"je_7711","ledger":"available","delta":-6208},
    {"journal_entry_id":"je_7712","ledger":"reserved","delta":-192}
  ],
  "export":{
    "type":"FINANCE_CSV",
    "hash":"sha256:..."
  }
}

12) Operational Playbooks

Payout failure playbook

  • Classify failure: beneficiary invalid vs corridor outage vs compliance hold
  • Request new plan: POST /v1/payouts/plan
  • Reroute if p_fail improves materially
  • Escalate to manual review for repeated returns

Liquidity drain playbook

  • Enforce minimum float thresholds via rules
  • Auto-schedule non-urgent payouts
  • Increase holdback during disruption windows
  • Use netting to reduce outbound volume

Integration Notes

  • Use /v1/payouts/plan when you need route/timing optimization or when conditions change (FX spikes, corridor outages).
  • Always use Idempotency-Key for payout creation and treat webhooks as the source of truth for final state.
  • Send outcomes via /v1/events/outcomes to keep routing, failure probabilities, and cost models calibrated.

For enterprise rollout, security review, and settlement configuration, contact hello@spyface.com.