Accepting credits

Experimental. No named API credit provider integration is currently available to enable in production.

As a merchant, you sell API access and receive token payments. Accepting an API credit provider lets a customer fund those payments from the provider's balance. You do not issue the customer's credits or maintain the provider's ledger.

You choose which providers you trust and which payment flows your API supports. A provider's promise of payment is not enough: the payment verifier must validate the transaction and its result before granting access.

If you use Pay

Merchant policy is configured beside accepted currencies:

operator:
  currencies:
    usd: [USDC, USDT]
  credit_providers: []

An omitted list is empty. This configuration enables no API credit providers and preserves ordinary payment behavior.

Named provider selection is the merchant-facing configuration point, but the current implementation rejects unavailable providers at startup and during payment handling. There is no working provider name to add today. Do not use raw hook JSON from a customer as a substitute for a reviewed integration.

When an integration becomes available, check its supported network, currency, and payment flow before selecting it. Your endpoint pricing still determines what the customer pays; provider acceptance determines which credit-funded path may satisfy that price.

If you use pay-kit directly

The Rust SDK exposes PayKitConfig.credit_providers alongside currency. Its default is empty, and construction validates provider availability. The same availability restriction applies as in Pay.

With the SDK's axum feature enabled, the merchant configuration looks like this. An empty provider list keeps ordinary payments enabled without activating credit-funded payments:

use solana_pay_kit::PayKitConfig;

fn merchant_config(recipient: impl Into<String>) -> PayKitConfig {
    PayKitConfig {
        recipient: recipient.into(),
        currency: "USDC".into(),
        network: "devnet".into(),
        credit_providers: vec![],
        // Supply your RPC, signer, and challenge secret through service setup.
        // Never embed production keys or secrets in source code.
        ..Default::default()
    }
}

Existing lower-level MPP configuration targets the earlier experimental hooked flow. Pay and pay-kit were not updated in the same-address runtime revision and must not be assumed to emit its new WithHooks instructions. Configuration alone does not activate a named provider or establish issuer authorization. See Providing credits if you are building that integration.

Choose the payment flow

These are the channel-backed paths an integration must support, not currently available named provider options. Ordinary direct-transfer charges are unchanged, and x402 API credit provider support is not part of this implementation.

Plan for failures and restarts

• Understand the hook boundary. The channel checks protected balances and token controls around callbacks. A distribution callback cannot successfully remove merchant funds; provider refund recovery is limited to actual returned principal. These checks do not eliminate provider outages or upgrade-authority risk.
• Use durable storage. Pay's experimental hooked-session support requires Redis and is unavailable in Connect's memory-backed session path. Direct SDK integrations must preserve session state and use a durable store for charge submission and receipt records.
• Keep the original configuration. Recovery must use the channel's saved provider policy and hook commitment, not whatever defaults are configured after a restart.
• Treat callbacks as an availability dependency. A failing mandatory provider callback can block funding or distribution. Failed transactions roll back transfers, but can still cost fees.
• Check transaction support. Provider callbacks add accounts and data to a payment. Confirm that the complete transaction fits the limits supported by your wallet, client, and network; do not assume support for ordinary payments is sufficient.

The program supports standard channels and channels with hooks at the same address. This revision has not been deployed. Before enabling an integration, verify the deployed program, client support, and the full customer-to-merchant flow, including failure and recovery.