v6.8.0 - 2026-08-20

Release notes for Voltage Payments API release v6.8.0, published 2026-08-20.

• Added configurable processing fees for supported sends and receives, with separate send_basis_points and receive_basis_points rates. Wallet policies can override the wallet’s current line-of-credit rates, including an explicit zero rate. Rates are fixed when a payment starts.
• Fixed-amount receive requests now include the configured receive processing fee in the amount presented to the payer. Submit only the intended principal: the API calculates the fee and includes it in the generated payment request, while requested_amount remains the principal. On sends, the processing fee is charged to the sending wallet in addition to the principal and network fee.
• Payment responses and webhooks now expose optional top-level processing_fee terms, including the snapshotted rate and server-calculated amount. Use the returned amount when displaying the fee. These terms are omitted for fee-free payments and historical payments whose original terms cannot be reconstructed.
• Added an optional payment_breakdown separating principal, network fees, and processing fees. Payment-level breakdowns aggregate partial receives; payment-scoped wallet ledger entries provide settlement details. For cross-currency payments, use the returned breakdown rather than recalculating fees from the displayed principal. Provisional breakdowns can change as wallet settlement finalizes conversion and rounding.
• Billing line items now expose optional processing_fees totals split into send and receive amounts. These are informational accounting totals, separate from the bill amount due and Voltage’s volume fee.
• Added payout_holdback controls for USD lines of credit. Retain a percentage of each bill’s gross ACH payout or enough funds to reach a fixed reserve target in cents. Held-back funds remain in the customer’s USD wallets; a holdback is a reserve, not a fee. The default none mode preserves full payouts.
• Lightning sends now accept an explicit zero max_fee to require a zero-fee route. This limit applies to network/provider fees; configured processing fees are additional.
• Added structured context to supported policy and line-of-credit errors, and recorded payment policy validation failures for subsequent reads.
• Fixed browser cross-origin access to authenticated Checkout settings for configured management origins.

Integration notes

• Use processing_fee for fee configuration. Omitting it leaves the configuration unchanged, an object sets exact rates, and null clears it. Clearing a wallet override restores line-of-credit inheritance. Configuration PATCH requests return 202 Accepted; wait for reads to reflect the change before creating payments that depend on it.
• Processing-fee changes through the public line-of-credit PATCH route are limited to non-Mainnet lines of credit. Mainnet line-of-credit fee changes require administrator access. Wallet processing-fee overrides support all networks. USD payout holdbacks can be updated through the public line-of-credit route, including on Mainnet.
• Fee-configuration PATCH bodies reject unknown keys. The public field name is processing_fee; earlier development names such as customer_fee are not supported aliases.