Cash advance

Status: designed and built, but not operable

The logic is implemented and tested, but the entire cash advance domain has no persistence: no table for LP accounts, reputation, auctions, obligations or claims. No buyer can be matched to a liquidity provider, and no stage-2 release can fire. It is only a library. See Roadmap.

What it is for

Someone with a credit card wants cash, and a bank charges a lot for it. A cash advance usually costs 4–5% plus 20%+ interest from day one, and a balance transfer charges a fee too. Here, their card pays for another person's purchase, and that person's money comes back to them as cash. The target cost is a few percent. It has not been measured.

So the intended uses are a cash advance and paying off another card, the job a balance transfer does. A 0% intro APR card is one case of it, not the whole of it.

Three things the name does not say:

• The cash is not instant. It comes back in stages over days to weeks, as the goods are delivered and the return window closes.
• To the card issuer it is an ordinary purchase, not a cash advance. The name says what the cardholder ends up with. An issuer can still read it as manufactured spending; see issuer risk below.
• It is one mechanism, whatever the card. A cash advance, a balance transfer and a 0% promo route purchases the same way. The only difference is a deadline: a promo card carries its promo end date, and supply stops 21 days before it. An ordinary card has no such cliff; its deadline is the monthly bill.

In the code this is the credit line (credit_line), and the cardholder is the liquidity provider (LP). The rest of this page uses those names.

At a glance

1. CardholderSets a spending budget for their card
2. BuyerOrders goods and pays a discounted price
3. SalvoHolds the buyer's money in escrow
4. Cardholder's cardBuys the goods, which ship to the buyer
5. SalvoPays the cardholder back once a tracker shows delivery

Most of the money comes back on delivery. The last 5% to 30%, the holdback, comes back when the 30-day return window closes. None of this runs yet: no order can be placed.

The obvious questions

Won't my bank close my card for this?

It could. Each purchase is an ordinary purchase to your bank, but a bank can still close a card it decides is being used this way, claw back rewards or freeze the balance. That risk is yours, it is outside our control, and you should know it before you sign up.

Will you put more through my card than I agree to?

That is the design. You would set a spending budget per time window, and the matcher refuses orders above it; our own limits can lower it further. The matcher has no caller and nothing is stored yet, so today it limits nothing.

What if the buyer returns the item?

In the first version only final-sale goods are allowed, so returns should be rare. A buyer who claims a return puts down a small refundable deposit, and the holdback is frozen rather than paid out. If the store's refund is confirmed, the buyer is paid from the holdback. The code counts anything above the holdback as a debt taken from your later payouts; that accounting is not wired and has no storage yet.

What if it never arrives, or the buyer lies about it?

The main payout waits for an independent parcel tracker to show delivery, and the buyer's word cannot block it. One exception is built but switched off: an early payout of up to half the order when it is placed, before delivery. If that were turned on, you could be paid part of an order that never arrives.

A buyer loses their deposit only if you dispute a return claim and your statement is accepted. If nobody answers within 45 days, the claim is upheld and the deposit returned. A buyer is refused only after 5 or more claims with over a quarter denied, and nothing records claim outcomes yet. No code handles a lost parcel; the plan is to sort it out by hand.

When do I get my cash?

In stages. Most of it when the parcel is delivered: 95% for final-sale goods. The rest 30 days later, if nobody has claimed a return. A claim can hold it for up to 45 more days. It is not instant.

What does it cost me?

Mainly the discount the buyer gets. You set a starting price and a floor, and the discount widens over time toward your floor until a buyer takes the order. We charge you no fee, though by design Salvo keeps part of the yield earned by lending the escrow it holds. On an ordinary card, add interest on the holdback if it lands after your bill. On a 0% promo card most of the financing is free, but the holdback can land after the promo ends. Either way, add any return that costs more than the holdback.

Why would a buyer use this instead of just buying it?

They pay less than the store price for goods they wanted anyway, delivered to their own address. The size of that saving has not been measured.

Is my card number safe?

The rule is that a cardholder's card is never kept in a form only we can open, and the custody guard refuses to break it. The cash advance does not collect card numbers yet. Who presses "buy" at the store is still open: the first design assumed our automation would use your card from the vault, and no code does either option yet.

What if I take an order and never buy the goods?

You are not paid, because nothing shows delivered, unless the early payout above were switched on. A written rule refuses a cardholder below 90% completion after 5 accepted orders, but nothing counts orders yet, so it cannot trigger. No code refunds the buyer in that case; the plan is to do it by hand.

Does it work on any card?

It is built to handle promo and ordinary credit cards the same way. It does not run on any card yet. A promo card stops taking orders 21 days before the promo ends. An ordinary card has no cutoff.

The arbitrage

A liquidity provider (LP) holds a credit card: an ordinary one, or one with a 0% APR promotional window.

A buyer wants goods now at a discount. The LP buys them on their card, and escrow repays the LP in stages. Most of it comes back on delivery. The holdback, 5 to 30% of the order depending on what was bought, comes back when the 30-day return window closes.

The discount is the buyer's saving and the LP's main cost. What else it costs depends on the card:

• An ordinary card. If the LP pays their bill in full and the delivery payment lands first, that part costs no interest. The holdback often lands after the bill, so the LP carries it at their purchase rate for a few weeks, or covers it from their own cash. They price that into the discount they set.
• A 0% promo card. The financing is free. Supply stops 21 days before the promo ends, but the holdback can still release after the window closes, because the 30-day return window is longer than the cutoff.

Either way, a return shortfall beyond the holdback is also the LP's cost.

Why settlement is staged rather than atomic

A gift card redeems in seconds. A physical good ships and can be returned, so paying the LP at purchase would leave nothing behind a return. Release is staged:

Stage	Trigger	Releases
1	Delivery confirmed	Everything except the holdback
2	Return window closes with no live claim	The holdback

Two details are load-bearing:

• The window runs from delivery, not from confirmation. A late carrier poll must not shorten the buyer's return period.
• A double stage-1 is refused. Releasing twice would pay out ~170% of the order.

Holdback sizing

The holdback, which makes a returning buyer whole, is sized by return-risk category:

• Final sale: lowest, with no return to fund.
• General merchandise: middling.
• Apparel: highest. It is returned constantly.

An unstated category defaults to the strictest, so omitting it cannot shrink the holdback.

Only final sale is switched on in the code, because the dispute machinery is built but has never run against a real return. Allowing returnable categories would make every order depend on it from the first day.

Return claims freeze rather than release

A return claim does not trigger a payout. It freezes the holdback and starts a resolution window.

• The claim needs a refundable bond: small enough that an honest buyer is not put off and gets it all back, large enough that fifty speculative claims cost something.
• The 45-day default window is long on purpose. Merchant refunds take weeks to post, and a shorter one would decide claims on timing instead of fact.
• If the window expires with no evidence from either side, the configured default is uphold, and the bond is returned regardless. Nobody proved the buyer wrong, and silence is not fraud.

Obligation accounting

When an LP owes more than current escrow covers, the shortfall becomes an obligation attached to their next release, oldest first. So an LP's history follows them through future flow, without reversing past payments.

Not wired. Obligation accounting has no production caller and no storage.

Issuer risk: the mitigation-resistant one

An issuer that reads this as manufactured spending can close the LP's account, claw back rewards or freeze the balance. Nothing in our system binds it, so the LP's exposure is largely outside our reach.

We can shape the volume:

• Per-LP velocity limits over a rolling window.
• Recipient diversity: one LP shipping to one address repeatedly is a pattern.
• Blend ratio: promo-arbitrage volume mixed with ordinary spend.
• Per-issuer tolerance, learned from outcomes: issuers that have shown friction get tighter limits.

Two of these were inert. One still is.

For most of the project's life, nothing read the velocity window, so each LP's usage only went up until every LP hit its limit for good. That is fixed, and a test that moves the real wall clock across the window's boundary shows it now rolls.

Issuer history is still inert. recordIssuerOutcome has no production caller, so the history stays empty and the tightening never engages. Wiring it to in-memory state would recreate the original bug while looking like a fix, so it waits for storage on purpose.

Delivery confirmation

Stage 1 depends on a carrier confirming delivery, behind a swappable seam. EasyPost was built and tested, then found to gate its tracking API behind a manual fraud review we could not clear. Swapping to ParcelsApp touched one implementation and the config. Nothing else moved, because the staged release, return window and obligation accounting never knew which carrier answered.

The evidence records which source answered, because a fixture-driven stage-1 release in production would pay most of an LP's money on a test double's word.