Smart Payments

Smart Payments is the routing engine that decides which stablecoins, from which wallets, are used to settle every payment a customer makes through Decal. The customer sees a single amount and taps once. Behind that tap, Decal evaluates the available tokens across the customer's connected wallets and assembles the cheapest, fastest path to the merchant.

This page covers what the engine optimizes for, the priority order it uses, and how the selection plays out in practice.

What it does

For every payment, Smart Payments answers two questions:

1. Which stablecoin (or combination of stablecoins) should fund this payment?
2. Which of the customer's connected wallets should the funds come from?

The answer is determined automatically. Customers don't pick tokens or wallets — they confirm a total in dollars and Decal handles the rest. Improving the payment experience by reducing customer friction.

Customer confirms $80 payment
            │
            ▼
Smart Payments evaluates:
  ├── Available tokens (USDC, USDG, PYUSD, USDT, ...)
  ├── Available wallets (each with its own balances)
  ├── Recipient state (do they have a token account?)
  └── Preferred tokens
            │
            ▼
Optimal selection assembled into a single transaction

The selection is deterministic — given the same inputs, Decal always picks the same path.

The selection priority

Smart Payments evaluates candidates against a fixed priority list, in order. Earlier criteria always win over later ones.

When two candidates tie at one level, the algorithm advances to the next. The result is a stable, explainable selection that customers and merchants can both reason about.

Single-token capability

Whenever a single token can cover the entire payment amount, Decal prefers it. Splitting across two tokens means two transfers in a single transaction, which costs more in compute fees and adds complexity. A clean, single-token transfer is always the first choice when available.

Recipient account existence

Solana token accounts must exist before a token can be received. If the recipient already has an account for a candidate token, that token is preferred — no account creation cost (~$0.005). If they don't, Decal generally avoids that token to save the customer the fee, unless overridden for a preferred token (more on that below).

Preferred tokens

Decal may partner with select stablecoin issuers, either directly in an official capacity or via open protocols. When all other factors tie, preferred tokens are selected first. For example, if a customer holds StablecoinA (preferred) and StablecoinB in equal amounts and either can fund the payment, Smart Payments picks StablecoinA.

The reason this preference exists — and why it sits ahead of balance size — is that preferred stablecoins typically come with a customer-facing incentive layer: cashback on payments, points, fee rebates, yield, or other rewards that the issuer (or Decal) attaches to the token. Preferring preferred tokens at pay time routes customers into those reward flows automatically. They don't have to think about which token earns rewards or manually pick the right one — they hold the preferred stablecoin, and Smart Payments uses it whenever it can.

For customers, this means the rewards layered on a preferred stablecoin actually get used. A cashback program is only valuable if the token gets spent; Smart Payments makes sure it does.

For merchants, the priority is invisible. You receive the same settled amount in your accepted currency regardless of which stablecoin funded the payment. The benefit accrues to the customer (rewards) and to the partner issuer (transaction volume and adoption), with no impact on what hits your settlement destination.

For the payment itself, the priority is a tiebreaker — it never overrides the cost-saving rules above it. Single-token capability and recipient account existence both win first, so customers never pay extra fees just because a token is preferred.

Preferred tokens may also have account creation enabled, which lets them win even when the recipient doesn't already have an account for them. This is configured per partnership and helps seed broader adoption of the preferred stablecoin.

The priority is deterministic and disclosed — there is no hidden bias beyond what's described here.

Balance size

When everything above is equal, the token with the larger available balance wins. This keeps balances roughly proportional and avoids draining one token to zero when another would work identically.

Multi-token splits

When no single token can cover the payment, Smart Payments combines tokens to reach the total. The selection still runs through the priority list — preferred tokens are pulled to their full available balance first, then the next-priority token covers the remainder.

Customer wallet:  USDG: $50    USDC: $100
Payment amount:   $120

Selection:        USDG: $50  (drained)
                  USDC: $70  (covers remainder)

Result:           One transaction, two transfers, $120 settled

A few rules govern splits:

• The cap is small (typically two tokens). Decal won't fragment a payment across many tiny balances if it can be avoided.
• All transfers happen atomically in a single transaction — partial failure isn't possible.
• The customer sees the breakdown before confirming.

Cross-wallet aggregation

Customers can connect multiple wallets to Decal. Smart Payments treats every connected wallet as part of a single pool of spending power. A payment can pull from one wallet or compose across several, depending on where the optimal balances sit.

Wallet A (Phantom):    USDC: $40
Wallet B (Solflare):   USDC: $50
Payment amount:        $80

Selection:             $40 from Wallet A USDC
                       $40 from Wallet B USDC

This is what makes Smart Balance the spendable number it is — the headline balance reflects the total across all wallets, and Smart Payments is the engine that actually pulls from those wallets at pay time.

When the same token exists in multiple wallets, Decal generally consolidates from the largest balance first to minimize transfers.

Examples

These walk through the priority list with concrete inputs.

Single token covers it

Payment: $80 → Selection: USDC $80

USDC is the only token that can cover the full amount in a single transfer. Priority #1 ends the search.

Preferred token wins on equal footing

Payment: $75 → Selection: USDG $75

Both can cover the full amount (Priority #1: tie). Both have existing accounts (Priority #2: tie). USDG is preferred, so it wins on Priority #3 — even though USDC has a much larger balance.

Multi-token split, preferred token maximized

Payment: $120 → Selection: USDG $50 + USDC $70

Neither token alone can cover the payment (Priority #1 fails for both). USDG is preferred, so it's drained first; USDC covers the remainder.

Account existence beats preferred priority (default)

Payment: $75 → Selection: USDC $75

Both can cover the payment (Priority #1: tie). But USDG would require creating a recipient account, and account creation isn't enabled for this partnership. Priority #2 favors USDC. The customer saves on fees.

Single-token capability beats preferred priority

Payment: $80 → Selection: USDC $80

USDG can't cover the full amount; USDC can. Single-token capability (Priority #1) wins outright, even though USDG is preferred.

What customers see

Customers don't pick tokens. They confirm a total amount, and the breakdown is shown in the transaction summary before they sign. Preferred tokens, splits, and the source wallets are all displayed transparently — there is no hidden selection.

After payment, the breakdown is preserved on the receipt and accessible via the order's payment records.

What this means for your integration

Smart Payments runs entirely on Decal's side. As a merchant integrator, there's nothing to configure — payments arrive at your settlement wallet via the rules described in Payment Routing, regardless of which stablecoins the customer used to fund them.

A few practical implications:

• Order responses include payment-method details. If you need to know what the customer paid with, that data is on the order's payment record.
• Test mode runs the same algorithm. Test orders and live orders share the same selection logic, so what you see in test mode reflects production behavior.

If you want to see the selection logic in action, run a test checkout with a multi-token wallet and inspect the resulting payment record on the order.

Related

• Smart Balance — the unified balance Smart Payments draws from
• Payment Routing — how settled funds reach your wallet after Smart Payments selects the source
• Orders — where the payment record (including the token breakdown) lives