Use Cases

When to use platform payment infrastructure

Soledgic is a payment layer for platforms where money flows to many destinations — creators, sellers, referrers, and buyers — and where the platform needs real-time visibility into every cent. These are the patterns it's built for.

Platform payment infrastructure becomes useful when the platform itself is the financial experience: splits happen at checkout time, creators have balances that accumulate across many sales, buyers hold stored balances, or payouts need to pass through compliance gates before reaching a bank account.

Platform payment infrastructure is the layer between your application and those outcomes. Below are the six signals that indicate you need it.

1

Multi-party revenue splits at checkout

Signal: You have multiple payees per transaction

When a buyer pays $100, that money may belong to multiple parties — creator, platform, perhaps a referral partner. Platform payment infrastructure applies the split atomically at checkout time: each wallet is credited in the same database transaction that records the payment, and the resulting payable state is immediately available to your product.

creator_maya gets $85, platform gets $15 — atomic on payment completion.
2

Creator earnings wallets with real-time balance tracking

Signal: Creators need to see what they've earned before they can withdraw

A creator dashboard that shows "your balance" needs a ledger-backed source of truth. Every checkout completion, refund reversal, and hold release moves through a double-entry ledger so the balance is the authoritative sum of all entries. Soledgic's creator_earnings wallet is that ledger account.

GET /v1/wallets?owner_id=creator_maya returns live balance in cents.
3

Payout orchestration with KYC/KYB gates

Signal: You need to disburse earnings to many creators, each with their own compliance state

ACH payouts to bank accounts carry regulatory obligations. Soledgic checks payout eligibility before a payout is requested and returns the reason a creator is not ready yet, such as pending KYB, no bank account linked, or balance below minimum. Your UI can show a clear next step from the same API.

GET /v1/participants/{id}/payout-eligibility → { eligible: false, reason: "kyb_pending" }
4

Buyer stored balances

Signal: Buyers need to fund a wallet before spending with creators

Pre-funded buyer balances are money movement, not loyalty points. `consumer_credit` wallets in Soledgic are buyer stored-balance accounts: they participate in the same double-entry system as creator earnings, so top-ups, purchases, and refunds stay connected to the ledger trail.

Buyer tops up $20 → buyer pays at checkout → creator earns, buyer balance decreases.
5

Escrow-style holds before fund release

Signal: Money should be locked until a condition is met (delivery confirmed, dispute window closed)

A marketplace where buyers pay now but delivery happens later has a trust problem. Soledgic's hold primitive locks funds in a creator's wallet and prevents payout until the hold is explicitly released. The release can be triggered by a webhook from your fulfilment system, a support decision, or a time-based cron — whatever your dispute window requires. Funds are never in limbo: they're on the ledger, just constrained.

POST /v1/holds creates the hold; POST /v1/holds/{id}/release frees it for payout.
6

Audit-complete transaction history for creators and platform ops

Signal: You need to answer "where did this dollar go?" for any transaction

Double-entry means every credit has a matching debit on the same ledger. A creator's earnings wallet growing by $85 and the platform fee account growing by $15 are two sides of the same journal entry — traceable back to a single checkout session ID. The wallet activity endpoint returns the full ledger history: credits, debits, holds, releases, reversals, and their originating references.

GET /v1/wallets/{id}/activity returns all ledger entries with checkout_session_id references.

The five-step resource flow

If any of the six signals above match your platform, the entire integration reduces to five API operations in sequence:

POST/v1/participantsCreate or update the creator (idempotent)
POST/v1/checkout-sessionsCollect payment — split applied atomically
GET/v1/wallets?owner_id={id}Read creator earnings balance
GET/v1/participants/{id}/payout-eligibilityVerify creator can receive a payout
POST/v1/payoutsDisburse to bank via ACH

Try it in sandbox

All five operations work with a test key (slk_test_*). Use POST /v1/sandbox/checkout/complete to simulate a successful payment without touching real money.

Start with the quickstart guide →