Quick Start - Consumer Prepaid Ledger

Enroll consumers, fund their prepaid balances, and issue cards that spend from them

This guide walks through a consumer prepaid card program from setup to a settled card transaction. In a consumer prepaid program, each consumer (an individual account holder) gets their own ISSUING financial account. You load funds into it, and their cards spend from that balance. For background, see Financial Accounts and Balances.

Consumer prepaid programs come in two models. The main difference is where the program's money is held and how funds are loaded:

Lithic-processed paymentsExternally-held funds (modular)
Who moves the moneyLithic, over ACHYour bank partner, outside Lithic
How funds are loadedACH payment from your external bank accountExternal payment that records a transfer made at your bank
External bank account requiredYesNo

Steps that are the same for both models are written once. Where the models differ, each one is described separately.

Step 1: Lithic provisions your program accounts

Once your program is configured, Lithic creates its program-level financial accounts. You don't need to make any API calls. To see them, list your financial accounts:

GET https://api.lithic.com/v1/financial_accounts

For a Lithic-processed payments program, the response includes the OPERATING and RESERVE accounts:

{
  "data": [
    {
      "token": "a722fcdc-f65b-5356-a684-6b0b85b562e5",
      "account_token": null,
      "type": "OPERATING",
      "status": "OPEN",
      "substatus": null,
      "user_defined_status": null,
      "nickname": null,
      "routing_number": "021115084",
      "account_number": "19692645025634",
      "is_for_benefit_of": false,
      "credit_configuration": null,
      "created": "2026-09-01T12:00:00Z",
      "updated": "2026-09-01T12:00:00Z"
    },
    {
      "token": "2f356338-bbd4-569c-827f-3b9dceac2bb9",
      "account_token": null,
      "type": "RESERVE",
      "status": "OPEN",
      "substatus": null,
      "user_defined_status": null,
      "nickname": null,
      "routing_number": "021115084",
      "account_number": "19692820433598",
      "is_for_benefit_of": false,
      "credit_configuration": null,
      "created": "2026-09-01T12:00:00Z",
      "updated": "2026-09-01T12:00:00Z"
    }
  ],
  "has_more": false
}
AccountLithic-processed paymentsExternally-held funds (modular)
OPERATING✓
RESERVE✓

Lithic-processed payments: OPERATING and RESERVE hold program funds at Lithic's bank partner.

Externally-held funds: no program-level financial accounts are returned. Your program's cash is held at your own bank partner, so the only financial accounts you work with are the consumer ISSUING accounts created in Step 2.

In both models, consumer balances never sit at the program level. Each consumer's funds live in their own ISSUING account.

Step 2: Create a consumer account holder

This step is the same for both models. Enroll the consumer as an individual account holder with Create Account Holder. This example uses the KYC_EXEMPT workflow, which enrolls the consumer without Lithic running identity verification. Your program must be approved by Lithic and your bank partner to use it. To have Lithic verify the consumer's identity instead, use the KYC_BASIC workflow. See Account Holders (Individuals).

POST https://api.lithic.com/v1/account_holders
{
  "workflow": "KYC_EXEMPT",
  "kyc_exemption_type": "PREPAID_CARD_USER",
  "first_name": "Jane",
  "last_name": "Doe",
  "email": "[email protected]",
  "phone_number": "+15555550123",
  "address": {
    "address1": "123 Main Street",
    "city": "New York",
    "state": "NY",
    "postal_code": "10011",
    "country": "USA"
  }
}
  • phone_number is in E.164 format.
  • address can't be a PO box.

The response returns the new account holder:

{
  "token": "cac77737-3562-4770-a138-95e55e48d4a6",
  "account_token": "f1301db0-28e8-484c-9b7f-7f4984299aa9",
  "status": "ACCEPTED",
  "status_reasons": [],
  "created": "2026-10-05T13:55:02Z"
}
  • status: "ACCEPTED" means the consumer is enrolled and can be issued cards.
  • account_token identifies the consumer's account. You'll use it to link a bank account in Step 3 and to create a card in Step 5.

Lithic creates the consumer's ISSUING account automatically. To find it, list the financial accounts for the consumer's account_token:

GET https://api.lithic.com/v1/financial_accounts?account_token=f1301db0-28e8-484c-9b7f-7f4984299aa9
{
  "data": [
    {
      "token": "c7ecece7-6ce4-58d5-9fde-64974cb1f8ef",
      "account_token": "f1301db0-28e8-484c-9b7f-7f4984299aa9",
      "type": "ISSUING",
      "status": "OPEN",
      "substatus": null,
      "user_defined_status": null,
      "nickname": null,
      "routing_number": null,
      "account_number": null,
      "is_for_benefit_of": true,
      "credit_configuration": null,
      "created": "2026-10-05T13:55:02Z",
      "updated": "2026-10-05T13:55:02Z"
    }
  ],
  "has_more": false
}
  • account_token is the account_token from the account holder response above.

The token of the ISSUING account is the consumer's balance. You'll load funds into it in Step 4 and track it in Step 7.

Step 3: Add an external bank account (Lithic-processed payments only)

Externally-held funds: skip this step. Funds are loaded with external payments in Step 4.

Link the consumer's own bank account so you can pull funds from it over ACH. Lithic verifies that the consumer owns the account by sending two small deposits to it, which the consumer then confirms.

3a. Create the external bank account with Create External Bank Account:

POST https://api.lithic.com/v1/external_bank_accounts
{
  "verification_method": "MICRO_DEPOSIT",
  "owner_type": "INDIVIDUAL",
  "owner": "Jane Doe",
  "account_token": "f1301db0-28e8-484c-9b7f-7f4984299aa9",
  "type": "CHECKING",
  "routing_number": "<9-digit routing number>",
  "account_number": "<account number>",
  "country": "USA",
  "currency": "USD",
  "financial_account_token": "a722fcdc-f65b-5356-a684-6b0b85b562e5"
}
  • account_token is the consumer's account_token from Step 2. It links the bank account to the consumer.
  • type is CHECKING or SAVINGS.
  • financial_account_token is your program's OPERATING account from Step 1. The two micro-deposits are funded from it.

The response returns the bank account with verification_state: "PENDING":

{
  "token": "a036e6b5-fd0f-49b2-b0c0-45d84214b189",
  "account_token": "f1301db0-28e8-484c-9b7f-7f4984299aa9",
  "financial_account_token": "a722fcdc-f65b-5356-a684-6b0b85b562e5",
  "owner": "Jane Doe",
  "owner_type": "INDIVIDUAL",
  "type": "CHECKING",
  "routing_number": "<9-digit routing number>",
  "last_four": "6789",
  "name": null,
  "currency": "USD",
  "country": "USA",
  "verification_method": "MICRO_DEPOSIT",
  "verification_state": "PENDING",
  "verification_attempts": 0,
  "verification_failed_reason": null,
  "state": "ENABLED",
  "company_id": null,
  "user_defined_id": null,
  "created": "2026-10-05T13:58:40Z"
}

Save the token. It's the external bank account token you'll use in 3b and Step 4. The account_token and financial_account_token are the tokens you sent in the request. Lithic sends two deposits of between $0.01 and $0.99 to the consumer's bank account.

3b. Verify the micro-deposit amounts

Once the deposits arrive, the consumer tells you the two amounts. Submit them in cents with Verify Micro-Deposits, using the external bank account token from 3a in the path. The amounts can be in either order.

POST https://api.lithic.com/v1/external_bank_accounts/a036e6b5-fd0f-49b2-b0c0-45d84214b189/micro_deposits
{
  "micro_deposits": [19, 89]
}
Resultverification_state
Amounts matchENABLED. The account can now be used for ACH payments
Amounts don't matchStays PENDING, and the request returns 400
5 failed attemptsFAILED_VERIFICATION

If verification fails, or the deposits couldn't be sent (INSUFFICIENT_FUNDS), send new deposits with Retry Micro-Deposits, using the same external bank account token:

POST https://api.lithic.com/v1/external_bank_accounts/a036e6b5-fd0f-49b2-b0c0-45d84214b189/retry_micro_deposits

Step 4: Load funds into the consumer's account

How you load funds depends on your program's model. Each program uses one or the other: Lithic-processed payments programs can't create external payments, and modular programs can't create ACH payments.

Lithic-processed paymentsExternally-held funds (modular)
APIPOST /v1/paymentsPOST /v1/external_payments
Who moves the moneyLithic pulls it from the consumer's bank account over ACHYou move it at your bank partner, then record it with Lithic
Source of fundsThe external bank account from Step 3Wherever your bank partner received it

Option A: Lithic-processed payments (ACH payment)

Create an ACH collection that pulls funds from the consumer's verified bank account into their ISSUING account.

POST https://api.lithic.com/v1/payments
{
  "type": "COLLECTION",
  "method": "ACH_SAME_DAY",
  "financial_account_token": "c7ecece7-6ce4-58d5-9fde-64974cb1f8ef",
  "external_bank_account_token": "a036e6b5-fd0f-49b2-b0c0-45d84214b189",
  "amount": 10000,
  "method_attributes": {
    "sec_code": "WEB"
  },
  "memo": "Load funds"
}
  • financial_account_token is the consumer's ISSUING account from Step 2.
  • external_bank_account_token is the verified bank account from Step 3.
  • type is COLLECTION to pull funds in. (PAYMENT sends funds out to the bank account.)
  • method is ACH_SAME_DAY, so the debit settles the same banking day. It must be submitted before the daily same-day cutoff. ACH_NEXT_DAY is also available.
  • sec_code is WEB for consumer-authorized online debits, or PPD for consumer debits authorized in writing.
  • amount is in cents.

Lithic submits the ACH debit to the consumer's bank. Once it settles, the funds stay held for the ACH hold period (2 business days by default) to protect against returns. After that they become available to spend in the consumer's ISSUING account.

To check the payment's progress, retrieve it using the token returned when you created the payment:

GET https://api.lithic.com/v1/payments/656346c4-920c-4d8c-b4d1-41b4fab6c8ab

Once the funds have been released, the response looks like this:

{
  "token": "656346c4-920c-4d8c-b4d1-41b4fab6c8ab",
  "family": "PAYMENT",
  "category": "ACH",
  "type": "ORIGINATION_DEBIT",
  "status": "SETTLED",
  "result": "APPROVED",
  "direction": "DEBIT",
  "source": "CUSTOMER",
  "method": "ACH_SAME_DAY",
  "method_attributes": {
    "sec_code": "WEB",
    "ach_hold_period": 2,
    "addenda": null,
    "company_id": "<company id>",
    "receipt_routing_number": null,
    "recipient_name": null,
    "retries": 0,
    "return_reason_code": null,
    "return_addenda": null,
    "date_of_death": null,
    "trace_numbers": ["<trace number>"]
  },
  "financial_account_token": "c7ecece7-6ce4-58d5-9fde-64974cb1f8ef",
  "external_bank_account_token": "a036e6b5-fd0f-49b2-b0c0-45d84214b189",
  "blockchain_recipient_token": null,
  "related_account_tokens": {
    "account_token": "f1301db0-28e8-484c-9b7f-7f4984299aa9",
    "business_account_token": null
  },
  "currency": "USD",
  "pending_amount": 0,
  "settled_amount": 10000,
  "descriptor": "Load funds",
  "user_defined_id": null,
  "expected_release_date": null,
  "events": [
    {"type": "ACH_ORIGINATION_INITIATED", "amount": 10000, "result": "APPROVED", "detailed_results": ["APPROVED"], "created": "2026-10-05T14:02:11Z", "token": "595ded29-bd6a-4ed6-bf67-9aa693a70522"},
    {"type": "ACH_ORIGINATION_REVIEWED",  "amount": 10000, "result": "APPROVED", "detailed_results": ["APPROVED"], "created": "2026-10-05T14:02:12Z", "token": "5ed0ef54-3923-40d7-9f65-3ac5fe1fa07a"},
    {"type": "ACH_ORIGINATION_PROCESSED", "amount": 10000, "result": "APPROVED", "detailed_results": ["APPROVED"], "created": "2026-10-05T16:30:04Z", "token": "8d1f3ab8-46d1-412d-b3dd-730c8f238478"},
    {"type": "ACH_ORIGINATION_SETTLED",   "amount": 10000, "result": "APPROVED", "detailed_results": ["APPROVED"], "created": "2026-10-05T21:15:40Z", "token": "280305f9-7fdf-4571-8bfd-08ecd83a5ede"},
    {"type": "ACH_ORIGINATION_RELEASED",  "amount": 10000, "result": "APPROVED", "detailed_results": ["APPROVED"], "created": "2026-10-07T13:00:02Z", "token": "3de1c04b-59fb-53d3-a3bb-cd436e1c361d"}
  ],
  "created": "2026-10-05T14:02:11Z",
  "updated": "2026-10-07T13:00:02Z"
}
EventWhat happenedPayment status
ACH_ORIGINATION_INITIATEDLithic accepted the paymentPENDING
ACH_ORIGINATION_REVIEWEDThe payment passed reviewPENDING
ACH_ORIGINATION_PROCESSEDLithic sent the debit to the ACH networkPENDING
ACH_ORIGINATION_SETTLEDFunds received from the consumer's bank; the hold period starts. expected_release_date shows when the hold endsPENDING
ACH_ORIGINATION_RELEASEDHold period over; funds are available in the consumer's ISSUING accountSETTLED

settled_amount: 10000 and pending_amount: 0 confirm that the full amount is now available to spend. The financial_account_token, external_bank_account_token and related_account_tokens.account_token are the tokens from Steps 2 and 3.

Option B: Externally-held funds (external payment)

Your bank partner moves the money, so you record each load in three calls as it progresses.

4a. Create the external payment when the transfer is initiated at your bank:

POST https://api.lithic.com/v1/external_payments
{
  "category": "EXTERNAL_ACH",
  "payment_type": "DEPOSIT",
  "financial_account_token": "c7ecece7-6ce4-58d5-9fde-64974cb1f8ef",
  "amount": 10000,
  "effective_date": "2026-10-05",
  "token": "9e2b7c41-5d8a-4f3e-b6a1-0c4d8e2f7a93",
  "memo": "Load funds"
}
  • financial_account_token is the consumer's ISSUING account from Step 2.
  • category describes how the money moved at your bank: EXTERNAL_ACH, EXTERNAL_WIRE, EXTERNAL_RTP, EXTERNAL_FEDNOW, EXTERNAL_CHECK or EXTERNAL_TRANSFER.
  • payment_type is DEPOSIT to add funds. (WITHDRAWAL removes them.)
  • token is optional. If you supply it, it becomes the payment's token and makes the request idempotent.

4b. Settle it when your bank confirms the funds arrived, using the token from 4a in the path:

POST https://api.lithic.com/v1/external_payments/9e2b7c41-5d8a-4f3e-b6a1-0c4d8e2f7a93/settle
{
  "effective_date": "2026-10-06"
}

4c. Release it to make the funds available to spend, using the same token:

POST https://api.lithic.com/v1/external_payments/9e2b7c41-5d8a-4f3e-b6a1-0c4d8e2f7a93/release
{
  "effective_date": "2026-10-07"
}
  • effective_date is required for both settle and release.
AfterConsumer ISSUING balance
4a. CreateNo change
4b. Settlepending increases by the amount
4c. ReleaseFunds move from pending to available

If the funds have already arrived when you record them, pass "progress_to": "SETTLED" or "progress_to": "RELEASED" in the create request to skip the later calls.

Step 5: Create a card for the consumer

This step is the same for both models. Create a card linked to the consumer's account:

POST https://api.lithic.com/v1/cards
{
  "type": "VIRTUAL",
  "account_token": "f1301db0-28e8-484c-9b7f-7f4984299aa9",
  "memo": "Jane's prepaid card",
  "state": "OPEN"
}
  • account_token is the consumer's account_token from Step 2. It links the card to the consumer. Every card with this account_token spends from the consumer's ISSUING account, so a consumer with several cards has one shared balance.
  • type is VIRTUAL or PHYSICAL. Physical cards also need shipping_address and product_id.
  • state is OPEN so the card can approve authorizations right away.

The response returns the new card:

{
  "token": "affa1116-7893-40cb-8ca1-5217a2335823",
  "account_token": "f1301db0-28e8-484c-9b7f-7f4984299aa9",
  "card_program_token": "5e9483eb-8103-4e16-9794-2106111b2eca",
  "type": "VIRTUAL",
  "state": "OPEN",
  "substatus": null,
  "memo": "Jane's prepaid card",
  "last_four": "1098",
  "pan": "4111111149061098",
  "cvv": "070",
  "exp_month": "10",
  "exp_year": "2032",
  "cardholder_currency": "USD",
  "spend_limit": 0,
  "spend_limit_duration": "TRANSACTION",
  "hostname": "",
  "funding": null,
  "pin_status": "NOT_SET",
  "pending_commands": [],
  "product_id": null,
  "digital_card_art_token": null,
  "network_program_token": null,
  "bulk_order_token": null,
  "replacement_for": null,
  "created": "2026-10-07T14:10:00Z"
}
  • spend_limit: 0 means the card has no card-level limit. The consumer can spend up to the available balance of their ISSUING account. Set spend_limit and spend_limit_duration to add a tighter limit for each card.
  • pan and cvv are returned only to PCI-compliant programs in production.

Step 6: Authorize a transaction

In production, authorizations arrive from the card network when the consumer uses their card. Lithic approves an authorization only if its amount is within the available balance of the consumer's ISSUING account.

In sandbox, simulate a $25.00 purchase with Simulate Authorization, using the card from Step 5:

POST https://sandbox.lithic.com/v1/simulate/authorize
{
  "pan": "4111111149061098",
  "amount": 2500,
  "descriptor": "SoHo Bodega",
  "mcc": "5411",
  "merchant_acceptor_city": "NEW YORK",
  "merchant_acceptor_state": "NY",
  "merchant_acceptor_country": "USA"
}
  • pan is the card number from the Step 5 response.
  • amount is in cents.
  • descriptor is the merchant name, up to 25 characters.
  • status defaults to AUTHORIZATION, a purchase that needs a later clearing to settle.

The response returns the token of the new card transaction:

{
  "token": "fabd829d-7f7b-4432-a8f2-07ea4889aaac",
  "debugging_request_id": "d31645af-da9e-4952-b7dc-3ffb06618b39"
}

Save the token. You'll use it to retrieve the transaction and, in sandbox, to clear it in Step 7.

To see the result, retrieve the card transaction using that token:

GET https://api.lithic.com/v1/transactions/fabd829d-7f7b-4432-a8f2-07ea4889aaac
{
  "token": "fabd829d-7f7b-4432-a8f2-07ea4889aaac",
  "account_token": "f1301db0-28e8-484c-9b7f-7f4984299aa9",
  "card_token": "affa1116-7893-40cb-8ca1-5217a2335823",
  "financial_account_token": "c7ecece7-6ce4-58d5-9fde-64974cb1f8ef",
  "status": "PENDING",
  "result": "APPROVED",
  "network": "MASTERCARD",
  "network_risk_score": null,
  "acquirer_fee": 0,
  "authorization_code": "071471",
  "amounts": {
    "cardholder": {"amount": 0, "conversion_rate": "1.000000", "currency": "USD"},
    "hold": {"amount": -2500, "currency": "USD"},
    "merchant": {"amount": 0, "currency": "USD"},
    "settlement": {"amount": 0, "currency": "USD"}
  },
  "merchant": {
    "acceptor_id": "<merchant acceptor id>",
    "acquiring_institution_id": "<acquiring institution id>",
    "descriptor": "SoHo Bodega",
    "mcc": "5411",
    "city": "NEW YORK",
    "state": "NY",
    "country": "USA",
    "postal_code": null,
    "street_address": null,
    "phone_number": null
  },
  "service_location": null,
  "pos": {
    "entry_mode": {"card": "NOT_PRESENT", "cardholder": "NOT_PRESENT", "pan": "ECOMMERCE", "pin_entered": false},
    "terminal": {"attended": false, "card_retention_capable": false, "on_premise": false, "operator": "UNKNOWN", "partial_approval_capable": false, "pin_capability": "NOT_CAPABLE", "type": "UNKNOWN"}
  },
  "avs": null,
  "cardholder_authentication": null,
  "token_info": null,
  "tags": {},
  "events": [
    {
      "type": "AUTHORIZATION",
      "result": "APPROVED",
      "detailed_results": ["APPROVED"],
      "effective_polarity": "DEBIT",
      "amounts": {
        "cardholder": {"amount": 2500, "conversion_rate": "1.000000", "currency": "USD"},
        "merchant": {"amount": 2500, "currency": "USD"},
        "settlement": null
      },
      "network_info": {
        "acquirer": {"acquirer_reference_number": null, "retrieval_reference_number": "<retrieval reference number>"},
        "amex": null,
        "mastercard": {"banknet_reference_number": "<banknet reference number>", "switch_serial_number": null, "original_banknet_reference_number": null, "original_switch_serial_number": null},
        "visa": null
      },
      "rule_results": [],
      "created": "2026-10-07T15:00:00Z",
      "token": "bbbf1e86-322d-11ee-9779-00505685a123"
    }
  ],
  "created": "2026-10-07T15:00:00Z",
  "updated": "2026-10-07T15:00:00Z"
}
  • status: "PENDING" and result: "APPROVED" mean the authorization was approved and the transaction is waiting to clear.
  • amounts.hold.amount: -2500 is the $25.00 held against the consumer's balance until the transaction clears.
  • financial_account_token is the consumer's ISSUING account from Step 2, which the purchase draws from. account_token is from Step 2, and card_token is the card from Step 5.

If the amount is more than the available balance, the authorization is declined: status is DECLINED, result is INSUFFICIENT_FUNDS, and the consumer's balance is unchanged.

Step 7: Track balances through the transaction lifecycle

📘

Use webhooks to keep balances up to date. Subscribe to the balance.updated webhook. Lithic sends it every time the consumer's ISSUING balance changes, and its payload contains the same balance object that GET /v1/financial_accounts/{financial_account_token}/balances returns. To follow each purchase as it moves from authorization to clearing, also subscribe to card_transaction.updated. See Types of Events.

Webhooks keep your application in sync as soon as anything changes, without polling. The GET requests below are useful for checking a balance on demand or reconciling, and they show what each webhook will contain at each stage.

A card purchase changes the consumer's balance twice: once when it's authorized, and again when it clears. These examples start from the $100.00 loaded in Step 4.

7a. Check the balance after authorization

GET https://api.lithic.com/v1/financial_accounts/c7ecece7-6ce4-58d5-9fde-64974cb1f8ef/balances
{
  "data": [
    {
      "token": "c7ecece7-6ce4-58d5-9fde-64974cb1f8ef",
      "type": "ISSUING",
      "currency": "USD",
      "available_amount": 7500,
      "pending_amount": 2500,
      "total_amount": 10000,
      "last_transaction_token": "fabd829d-7f7b-4432-a8f2-07ea4889aaac",
      "last_transaction_event_token": "bbbf1e86-322d-11ee-9779-00505685a123",
      "created": "2026-10-05T14:02:11Z",
      "updated": "2026-10-07T15:00:00Z"
    }
  ],
  "has_more": false
}

The $25.00 has moved from available_amount to pending_amount. The consumer can now spend only the remaining $75.00. total_amount is unchanged because no money has left the account yet.

  • token is the consumer's ISSUING account from Step 2.
  • last_transaction_token and last_transaction_event_token are the card transaction and its authorization event from Step 6.

7b. Clear the transaction

In production, the merchant clears the transaction through the card network, usually within a few days. In sandbox, simulate the clearing with Simulate Clearing:

POST https://sandbox.lithic.com/v1/simulate/clearing
{
  "token": "fabd829d-7f7b-4432-a8f2-07ea4889aaac"
}
  • token is the card transaction token from Step 6.
  • amount is optional. If you leave it out, the full authorized amount is cleared. Set it to simulate a final amount that differs from the authorization, such as a tip.

The response returns only a debugging_request_id. Retrieve the card transaction again to see the result:

GET https://api.lithic.com/v1/transactions/fabd829d-7f7b-4432-a8f2-07ea4889aaac

The transaction is now SETTLED, with a CLEARING event added. The other parameters are unchanged from Step 6:

{
  "token": "fabd829d-7f7b-4432-a8f2-07ea4889aaac",
  "status": "SETTLED",
  "result": "APPROVED",
  "amounts": {
    "cardholder": {"amount": -2500, "conversion_rate": "1.000000", "currency": "USD"},
    "hold": {"amount": 0, "currency": "USD"},
    "merchant": {"amount": -2500, "currency": "USD"},
    "settlement": {"amount": -2500, "currency": "USD"}
  },
  "events": [
    {
      "type": "AUTHORIZATION",
      "result": "APPROVED",
      "detailed_results": ["APPROVED"],
      "effective_polarity": "DEBIT",
      "amounts": {
        "cardholder": {"amount": 2500, "conversion_rate": "1.000000", "currency": "USD"},
        "merchant": {"amount": 2500, "currency": "USD"},
        "settlement": null
      },
      "created": "2026-10-07T15:00:00Z",
      "token": "bbbf1e86-322d-11ee-9779-00505685a123"
    },
    {
      "type": "CLEARING",
      "result": "APPROVED",
      "detailed_results": ["APPROVED"],
      "effective_polarity": "DEBIT",
      "amounts": {
        "cardholder": {"amount": 2500, "conversion_rate": "1.000000", "currency": "USD"},
        "merchant": {"amount": 2500, "currency": "USD"},
        "settlement": {"amount": 2500, "conversion_rate": "1.000000", "currency": "USD"}
      },
      "created": "2026-10-08T09:30:00Z",
      "token": "8d4f88f0-16e9-4755-832e-b09f00c587fc"
    }
  ],
  "updated": "2026-10-08T09:30:00Z"
}
  • The AUTHORIZATION event is the same event from Step 6.
  • amounts.hold.amount is back to 0 because the hold has been replaced by the final settled amount.
  • amounts.settlement.amount: -2500 is the final amount debited from the consumer's account.

7c. Check the balance after clearing

GET https://api.lithic.com/v1/financial_accounts/c7ecece7-6ce4-58d5-9fde-64974cb1f8ef/balances
{
  "data": [
    {
      "token": "c7ecece7-6ce4-58d5-9fde-64974cb1f8ef",
      "type": "ISSUING",
      "currency": "USD",
      "available_amount": 7500,
      "pending_amount": 0,
      "total_amount": 7500,
      "last_transaction_token": "fabd829d-7f7b-4432-a8f2-07ea4889aaac",
      "last_transaction_event_token": "8d4f88f0-16e9-4755-832e-b09f00c587fc",
      "created": "2026-10-05T14:02:11Z",
      "updated": "2026-10-08T09:30:00Z"
    }
  ],
  "has_more": false
}

The pending $25.00 has left the account. available_amount stays at $75.00, and total_amount drops to match it. last_transaction_event_token is now the clearing event from 7b.

Summary

AfterCard transaction statusavailable_amountpending_amounttotal_amount
Step 4: funds loadedn/a$100.00$0.00$100.00
Step 6: authorization approvedPENDING$75.00$25.00$100.00
Step 7b: clearingSETTLED$75.00$0.00$75.00

If the authorization is reversed or expires instead of clearing, the transaction becomes VOIDED or EXPIRED, and the held $25.00 returns to available_amount. See Transaction Flow for every card transaction path.


Did this page help you?