Mixed Payment

Overview

One invoice can be funded in more than one step

Mixed payment describes a controlled workflow in which a customer completes an invoice with more than one eligible cryptocurrency payment. For example, the customer may send most of an invoice using one asset and finish the remaining amount using another supported asset. The concept is not the same as swapping one token for another or combining coins secretly inside a wallet. The payment system must explicitly allow the behavior, calculate the remaining obligation and decide when that combined value satisfies the invoice.

How the underlying system works

A mixed-payment workflow must track the remaining balance after each accepted contribution. Because coins can have different units and exchange rates, systems should preserve the conversion or valuation basis used for each component and avoid assuming that two nominal quantities are directly comparable. Unsupported assets or networks should never be silently accepted as a valid second component.

It is also important not to confuse a mixed payment with a checkout that merely offers multiple currencies. A choice screen with many assets is not itself mixed payment: the customer must actually use more than one payment component toward the same obligation. Reporting must be able to show each blockchain transaction as well as the consolidated invoice result.

A simple $100 example

A checkout requests the equivalent of $100. The customer initially sends assets worth $65. Instead of restarting the whole purchase, a mixed-payment-enabled invoice can show an unpaid remainder that the customer may cover with another supported currency. When the second payment arrives, the system must convert each accepted contribution to the invoice's chosen valuation basis according to its documented rules. It checks both networks, recipients, amounts and confirmation states before crediting the same commercial invoice. OxaPay's invoice API has a mixed_payment option that permits another currency to cover an outstanding remainder after an underpayment. It does not imply every arbitrary token or chain is accepted.

Where the complexity hides

Rates can move between the first transfer and the second, and the two payments may have different network fees. The merchant needs a clear rule for valuing each contribution, calculating the remainder and preventing double credit. If the first payment is still unconfirmed or the invoice has expired, blindly inviting a second transfer can create a confusing customer experience. Store the invoice reference and both transfer records; otherwise a combined payment can look like two unrelated sales. Mixed payment improves flexibility, but only when aggregation and exception handling are reliable.

Further reading and related concepts

Reference documents: OxaPay — Generate Invoice.

Related glossary topics: Crypto Invoice, Underpayment Coverage, Crypto Payment Status.