Financial
Payments and rails
Abode currently supports Stripe-backed card and ACH collection. The payment layer is still worth describing as a rail orchestration surface because any future rail, including stablecoins, has to fit the same pending-state, ledger, and accounting model rather than bypassing it.
Live collection rails
Stripe card and Stripe ACH
Settlement posture
Pending payment records and provisional ledger visibility before final confirmation
Future architecture
Stablecoin rails would need wallet, chain, and confirmation handling that is not live today
Interactive example
Collection rail preview
Switch between live Stripe rails and a proposed stablecoin architecture view to see how the provider, returned artifact, and accounting behavior would differ.
Request builder
Switch between live Stripe rails and a future stablecoin architecture example to see how provider, returned artifact, and settlement posture would change.
Request payload
{
"amount": 1845,
"paymentMethodType": "card",
"autopay": true
}Returned artifact
{
"clientSecret": "pi_3Q..._secret_...",
"paymentId": "pay_01J8V17N4VJ8EFQSKHP7PFGYHB"
}Rail infrastructure
Card
Card payments stay inside the familiar Stripe path but still create Abode-native pending records so collections and accounting stay aligned.
- Provider
- Stripe PaymentIntent
- Response artifact
- clientSecret + pending payment record
- Settlement
- Fastest resident checkout with immediate client-secret handoff.
- Operator state
- Pending card payment + provisional tenancy ledger entry
- Accounting effect
- Pass-through fee gross-up is available when the org uses an active connected account.
- Treasury path
- Best for standard portal checkout where speed matters more than fee minimization.
Underlying stack
Card and ACH run through live Stripe collection primitives today. Stablecoin settlement is not live; if added later, it should introduce explicit wallet, chain, and confirmation state without bypassing the accounting model.
Video guide
Payments and rails guide
A short Remotion walkthrough of today's Stripe collection flow and the accounting constraints any future rail would need to preserve.
Duration
0:28
Coverage
Video guide · Rail infrastructure · Create a payment intent
Guided walkthrough
Rail infrastructure
Two live rails share one collection surface today, and a future stablecoin rail would need a meaningfully different settlement artifact.
| Rail | Provider | Returned artifact | Accounting posture |
|---|---|---|---|
| Card | Stripe PaymentIntent | clientSecret + paymentId | Pending payment and provisional tenancy ledger entry are visible immediately |
| ACH | Stripe us_bank_account | clientSecret + paymentId | Same pending-state handling, but with slower settlement expectations and lower fee drag |
| Planned USDC | Future wallet + chain provider | depositAddress + amountUsdc + chain metadata | Should remain pending until confirmation and ledger application complete |
Card and ACH both stay inside the Stripe branch of the create-intent route, but they are still first-class Abode payments rather than isolated checkout events. The route creates a pending payment record immediately so the operator can see an in-flight collection before Stripe settles it.
A future stablecoin rail would intentionally diverge. Instead of returning a Stripe client secret, it would need to return wallet and chain metadata so the rest of the system could treat settlement as a wallet-confirmation workflow rather than a synthetic card flow.
Create a payment intent
The current payment creation route branches by payment method type for card and ACH while enforcing tenancy ownership, amount limits, and connected-account policy.
/api/payments/create-intentCreates a Stripe payment intent for card or ACH collection.
- Authentication
- Tenant portal session
- Constraint 1
- The route verifies the tenancy belongs to the authenticated resident.
- Constraint 2
- Amounts above balance plus one month's rent are rejected.
- Constraint 3
- feeAmount and totalAmount are conditional response fields when fee pass-through is enabled and the connected Stripe account is active.
- Constraint 4
- ACH requires a Stripe customer and uses us_bank_account instead of the card path.
- Constraint 5
- The live route does not currently branch into a stablecoin settlement flow.
Request examples
curl https://app.theabode.ai/api/payments/create-intent \
-X POST \
-H "Authorization: Bearer {tenant_session}" \
-H "Content-Type: application/json" \
-d '{
"tenancyId": "tncy_01J8V10SMN6F5PZ5Q2ATK8H1RQ",
"amount": 1845.00,
"paymentMethodType": "card"
}'Response examples
{
"clientSecret": "pi_3Q..._secret_...",
"paymentId": "pay_01J8V17N4VJ8EFQSKHP7PFGYHB"
}Implementation note
The route is not just validating input and proxying a provider response. It resolves the tenant's real tenancy, applies payment caps, determines connected-account behavior, and normalizes each rail into an Abode payment record the rest of the platform can reason about.
Future stablecoin architecture
Stablecoin rails are not live today, but the shape of a safe implementation is still worth documenting so future work does not bypass the accounting model.
- A future stablecoin rail should use org-scoped receiving wallets rather than a shared omnibus address so money movement can still map cleanly to the property and tenancy record.
- If Circle or a similar provider is used, Abode would need to persist wallet, address, and chain metadata in the local payment model before calling the rail production-ready.
- If Arc or another chain is used for settlement, the pending payment should carry explicit chain metadata so later confirmation work can reconcile the transfer against the original collection request.
- No production stablecoin branch is live today, so these behaviors should be read as architecture guidance rather than current operator workflow.
Where SwapKit fits
If Abode adds conversion or liquidity routing at the edge later, a SwapKit-style layer belongs around treasury movement and wallet funding, not inside the resident-facing Stripe collection surface.
Settlement and ledger behavior
Payment creation is only the first step. The live Stripe flow and any future rail should both treat confirmation, balance updates, and trust handling as linked operating concerns.
- Stripe flows create a pending payment record immediately so the operator can see the in-flight payment without waiting for webhook completion.
- The tenancy ledger can receive a provisional pending-payment entry so projected balances stay visible while the payment is still processing.
- A future non-Stripe rail should not finalize collection until provider confirmation, balance application, and ledger writes all succeed together.
- If stablecoin settlement is added later, the implementation should store tx metadata, confirmation state, and failure timeout behavior explicitly rather than inferring them from Stripe-era fields.
- Trust-ledger recording and treasury movement should remain downstream of confirmed collection rather than being handled optimistically.
Collection decisions should flow directly into accounting visibility
Collections, exceptions, and payment status should be visible next to balances and expenses.