Execute an Award with Stripe Connect

A partner can bind a case to two linked Stripe connected accounts. Once the Award is served and executable, People’s Court debits the bound payer account and transfers the exact USD amount to the bound payee. Both provider receipts are recorded in the existing execution resource. The initial supported route is US/USD accounts on one platform with the required account-debit permissions and consent.

Link the accounts

An active tenant administrator opens Account → Integrations → Stripe connected accounts and selects Link a connected account. Stripe collects account information on its own onboarding page. Returning to the console does not establish readiness; refresh the provider status and complete any outstanding requirements. Account-link URLs are temporary and are never stored as credentials.

The console uses GET and POST /api/account/integrations/{partnerId}/stripe-connect under an authenticated account session. A POST carries an Idempotency-Key; an optional accountRecordId resumes a previously admitted account. The response contains the sanitized account, single-use onboarding URL and expiry. An unresolved account creation is reconciled by provider lookup before another account can be created for that identity.

Bind the case before the Award

Use the separately scoped settlement_adapter credential whose resource is stripe_connect. Both accounts must belong to the same tenant’s linked account inventory. The case binding records express authority to debit; linking an account is not that authority.

POST /api/cases/pcase_example/stripe-connect-binding
Authorization: Bearer <stripe-connect-executor-key>
Content-Type: application/json
Idempotency-Key: case-stripe-binding-1

{
  "payerConnectedAccountId": "acct_payer",
  "payeeConnectedAccountId": "acct_payee",
  "payerSide": "claimant",
  "amountUsd": 25,
  "debitConsentReference": "case-specific-consent-1",
  "authorizeAccountDebit": true
}

The amount must equal the case’s exact USD amount. The binding closes before Award preparation. It fixes the tenant, account identities, party mapping, consent reference and environment. A later request cannot substitute another payer or payee. GET on the same resource reads that binding.

Request and observe execution

Use POST /api/cases/{id}/executions with action: "request_release" and the served awardHash. Stays, appeals, timely post-Award requests and operational holds continue to control execution. Partial or conditional allocations require action; the executor does not change the Award to fit Stripe.

Read GET /api/cases/{id}/executions or GET /api/executions/{id}. The resource adds provider, providerOperation, providerReceipts and reconciliation. Test receipts remain simulated with paymentConfirmed: false. An unknown response is reconciled through the existing operation identity, even if a new HTTP idempotency key is supplied. Partner execution events are available through the existing signed webhooks and case event cursor.

The existing execution operations continue to handle execution. Console onboarding requires the administrator’s account session. MCP has no new execution capability.

Vacatur and correction

The original operation records recovery when its Award is vacated or replaced. Stripe must confirm the transfer reversal before the payer debit is refunded. reversed, reversal_pending and reversal_needs_action describe recovery separately from the original receipt. A paid-out or balance-constrained transfer may not be reversible. A corrected Award never silently reuses its predecessor’s payment as proof of performance.

Confirmed receipts remain subject to periodic provider checks even if a reversal callback is lost. The execution clock checks at most 25 due operations per sweep, with a durable 15-minute interval for confirmed receipts. Detection depends on clock cadence and backlog. An external reversal or refund while the Award remains operative changes the execution to reversal_needs_action and emits the existing execution event without issuing another debit.