Accept crypto payments at your food truck or market stall — no card terminal needed

Why accepting payments at a food truck is harder than in any restaurant

A restaurant has a wall socket, a router, a counter and a card terminal that never moves. A food truck, a farmers market stall, a pop-up or a festival vendor has none of those, and sells the same $8–$15 ticket at three times the pace, in a queue that gives up in about ninety seconds. The demand is there: IBISWorld counts 92,257 food truck businesses in the United States in 2025, growing 23.7% a year on average since 2020, and independent operators run more than nine in ten of them. What has not kept up is the till.

Four structural facts shape every payment a mobile vendor collects.

First, your terminal is a phone with a dongle — and the dongle is the weak link. The card reader pairs by Bluetooth, runs on its own battery, and rides on the phone's data connection. At a music festival with fifty thousand phones on one tower, at a market inside a stone hall, at a food truck rally in an out-of-town field, the connection stalls exactly when the queue is longest. Every vendor knows the ritual: hold the reader up, walk two metres, "sorry, cash only for a minute".

Second, your ticket is small and the fee is not. Card pricing for small merchants is typically a percentage plus a fixed amount per tap. On a $12 taco plate that structure lands closer to 4–5% than the headline rate — before the reader you bought, the replacement you keep in the glovebox, and the monthly software plan that unlocks the reporting you actually need.

Third, cash is still a third or more of your day — and cash is work. A float to prepare, change to keep, a box that walks around with a teenager on a Saturday, a count at midnight in the cab of a truck, a bank run on Monday, and no way to tell which helper's shift the shortfall came from.

Fourth, your big tickets are the most reversible ones. A wedding catering deposit, a corporate lunch for eighty, a festival pitch fee you pay the organiser and a food-and-beverage commission the organiser pays you: these move by card or by bank transfer, arrive days late or not at all, and the card-paid deposit can come back as a "services not rendered" dispute months after you bought the ingredients.

Five kinds of sale that behave nothing alike

• The queue. Dozens of $8–$15 tickets an hour, at a window, with a helper on the till and a second one on the grill. Speed is everything; a failed tap costs the next three customers.
• The market stall. Smaller tickets, more of them, often a mix of cash and card, in a hall or field with unreliable signal, and a table you break down at 2 pm.
• The pre-order. A regular texts "twelve burritos for 12:30". You want it paid before you cook it, and you do not want to hold a card number in a notes app.
• The private event. Weddings, corporate lunches, birthdays: a deposit weeks ahead, a balance the day before, and a client who may be in another city.
• The festival. A pitch fee to the organiser, sometimes a revenue share back, a token or wristband system you do not control, and a settlement that arrives by bank transfer whenever it arrives.

What the current setup actually costs a mobile vendor

The signal drop at peak. A Saturday night market, a queue of twenty, the reader spinning. Two customers pay cash, three walk, and the helper starts writing IOUs on a napkin. You will never know how much that hour lost, only that it happens every time the crowd is biggest — which is the only hour that matters.

The fee on a plate. Do the arithmetic on your own ticket: a percentage plus a fixed charge on a $12 sale, times four hundred sales a weekend, times forty weekends. For most single-truck operators the card fee alone is the largest "supplier" they never chose — bigger than the propane, in some cases bigger than the pitch fees.

The reader that died at 1 pm. It was charged last night. It was not. The spare is in the other truck. The rest of the day is cash-only, at a market where half the customers no longer carry any.

The cash count that does not add up. Three helpers, one box, a $60 gap at midnight. Nobody stole anything, probably. You will never find out, and you cannot ask without accusing.

The deposit that turned into a dispute. A corporate lunch for eighty, deposit paid on the office manager's card in April. The company restructures in June; in July an accounts department that never saw the email thread files a chargeback. The ingredients, the staff and the fuel were paid weeks ago; the dispute window the card network measures in months has only just started.

The festival settlement that arrived short. A three-day event on a token system: you serve two thousand plates, the organiser pays out by bank transfer "within 30 days", minus a commission, minus a "processing fee", minus a disputed reconciliation. You financed a weekend of stock on a promise.

The visitor who could not pay. A tourist at your stall in a market town, a foreign card declined at a tap-to-pay reader by an issuer that did not like the merchant category — or a traveller who left the country's cash behind and now holds dollars on a phone with nothing at your window to point them at.

Why card readers, cash and bank transfers each break at a food truck

None of these rails is badly designed. Each one assumes something a mobile vendor violates.

Card readers assume a fixed location. The whole stack — acquirer, terminal, merchant category, "card-present" pricing — was built around a shop that stays still, has power and can prove where a transaction happened. A truck that trades at a school on Tuesday, a brewery on Friday and a festival on Sunday is an anomaly the acquirer prices as risk and the hardware treats as an afterthought.

Card pricing assumes a large ticket. A fixed per-transaction charge disappears on a $90 restaurant bill and dominates a $6 coffee. The smaller and faster your tickets, the more of your margin the pricing model takes, by design.

Cash assumes you want to hold it. It is instant and final, which is why vendors still love it — and it is also uncountable per helper, a theft risk in a vehicle with one door, and increasingly the thing your customers do not carry. We wrote the general version in accept crypto payments in person; a food truck is that article with a queue and no wall socket.

Bank transfers assume the deadline is administrative. A festival organiser's settlement or a corporate client's balance crosses an accounts department, lands days later, sometimes short, and always after you paid for the stock. For an event deposit the wire is slow; the card is fast but reversible; neither is both fast and final.

All of them assume the customer's money lives in a local bank. A growing share of the people at a market — tourists, students from abroad, freelancers paid in dollars — already hold USDC or USDT on their phones. Today your window gives them nothing to point that balance at.

How Payzum lets a food truck accept crypto payments with no terminal at all

Payzum is a non-custodial, crypto-only payment processor. Both halves matter for a vendor with no fixed address.

Non-custodial means the money never sits in a Payzum balance. A customer pays from their wallet straight to a wallet you control. There is no processor float, no rolling reserve priced against a "mobile vendor" risk profile, no payout schedule, and no balance a risk desk can hold while it asks you for a lease you do not have. The settlement is the payment.

Crypto-only means the rail is on-chain and the payment is final once confirmed — roughly 0.4 seconds on Solana, around two seconds on Base and Polygon — with network fees measured in cents rather than a percentage of the plate. Turn on auto-convert to USDC or USDT and "crypto" never means price movement: whatever a customer pays with, what lands in your wallet is a dollar stablecoin. See USDT vs USDC for payments for how the two differ.

And there is no hardware. The Payzum POS runs in the phone you already hold at the window: it generates a new QR for every sale, the customer scans it with any wallet, and the screen turns green when the chain confirms. No reader to pair, charge, lose or replace; no lease; no acquirer; no card-network fees; and, because on-chain payments are final, no chargebacks.

The instruments, mapped to how a mobile vendor actually sells

• POS with a fresh QR per sale — the window. Type the amount, show the QR, watch it confirm. A new code for every ticket means no reused addresses and no "did that one go through?". Run it on two phones at a double window or on a tablet zip-tied to the counter. The setup walkthrough is in turning your phone into a crypto POS.
• PIN cashiers and per-cashier analytics — the helpers. Give each helper a PIN. Every sale is stamped with who took it, on which phone, at which event. At midnight you read a report instead of counting a box, and if a shift is short you know which shift. Mechanics in crypto POS with PIN cashiers.
• No-code payment links — pre-orders and private events. "Twelve burritos for 12:30" gets a link in the same text thread; the order is cooked when it confirms. A wedding or corporate deposit is a link the client pays from any city, irreversibly, and the balance is a second link the day before.
• Invoices with expiry, reference and overpayment detection — organisers and corporate clients. Put the event name as the reference, set the expiry to your hold on the date, and let the system flag the client who rounds up or adds the gratuity to the same payment. The money reconciles itself.
• Hosted checkout — your pre-order page. If you take orders on a simple web page or a menu link, put it behind a checkout that confirms in seconds, with no card-not-present fraud loss sitting on your side.
• CSV mass payouts and EVM stablecoin payouts — the people you pay. Weekend helpers, the second truck's crew, a commissary, a seasonal supplier: one file at the end of the week on Polygon, Arbitrum, Optimism, Base, BNB Chain or Avalanche, plus BTC, LTC and DOGE batches. Format in bulk crypto payments by CSV.
• REST API with signed webhooks — if you ever want it. Most single-truck operators never will. A multi-truck operator can have each confirmed payment update an ordering screen or a spreadsheet automatically, with a reference on every payment for the accountant.

What actually happens when a customer pays at the window

You type $12 and tap "charge". The phone shows a QR. The customer opens their wallet, scans, confirms. On Solana the confirmation is faster than a card tap; on Base or Polygon it is about two seconds. Your screen shows the sale as paid, tagged with the helper's PIN and today's location. The money is in your wallet — not in an acquirer's settlement batch, not on a card issuer's dispute clock, not in a cash box. If you set auto-convert, it is in USDC or USDT regardless of what the customer sent.

The change is not mainly speed. It is that a sale becomes real the moment it confirms, on a device you already own, with no third party between the customer and you.

Honest scope: what this does not do

It does not replace cash or cards; it adds a third way to pay with zero hardware, for the customers who already hold stablecoins, and it removes a line of fees and a box of cash for the share of sales it takes. It still needs the customer's phone to reach the network to send, and yours to see the confirmation — the same data connection your reader uses, minus the dongle. And on-chain payments are final: a refund under your policy is a payment you initiate from your wallet, so write the policy down before you need it.

How to set up crypto payments at your food truck, step by step

1. Create the merchant account and connect your wallet. Sign up at merchant.payzum.com, complete KYC, and enter the wallet address you control — a hardware wallet, a phone wallet, an exchange deposit address if that is where you want dollars to land. Payzum never holds a balance for you.
2. Choose the chains and turn on auto-convert. Enable the networks your customers actually use — Solana, Base and Polygon cover most wallets and confirm in seconds — and switch on auto-convert to USDC or USDT so every sale settles as a dollar stablecoin.
3. Open the POS on the phone at the window and add your helpers. Log in on the phone or tablet you already use, name it ("Window A", "Market stall"), and create a PIN for each helper. Print a small "we take USDC / USDT" sign for the menu board.
4. Sell. Amount, QR, confirmation, next customer. At the end of the day the per-cashier and per-terminal reports replace the cash count for this rail.
5. Add the off-window instruments as you need them. A payment link template for pre-orders and event deposits; an invoice template for organisers and corporate clients; a CSV payout at the end of the week for helpers and suppliers.

There is no integration, no code and no hardware order. Most vendors are taking their first payment the same afternoon they sign up.

Use cases: food trucks, market stalls, pop-ups and festival vendors

Four scenarios we see across mobile food and market vendors, with the instrument that fits each one.

• The taco truck at a brewery every Friday. Two hundred tickets in four hours, a helper on the till, a reader that used to drop when the beer garden filled. Now the phone shows a QR per sale, the helper has a PIN, and the owner reads a per-shift report from the cab instead of counting a box. The brewery's out-of-town visitors pay in USDC from a wallet they already had.
• The bakery stall at a Saturday farmers market. Small tickets, a stone market hall where the card reader never quite connected, and a $4 loaf that lost a fixed fee plus a percentage on every tap. The QR lives on a laminated card next to the till — refreshed per sale from the phone — and the stall's card-fee line falls with every customer who chooses it.
• The catering truck that does weddings. A deposit weeks ahead, a balance the day before, a couple planning from another city and a "services not rendered" chargeback the truck ate once and never wants to eat again. The deposit is a payment link paid in seconds and final; the balance is a second link; the invoice carries the event name and flags the tip the couple added to the same payment.
• The three-truck operator at a summer festival. Three windows, nine helpers, a pitch fee to the organiser and a revenue share back that used to arrive by bank transfer "within 30 days", short. Each truck is a named terminal with its own PINs and its own report; the organiser's share is invoiced with expiry and reference; the crew is paid Sunday night from one CSV instead of a stack of envelopes.

Payzum vs card reader, cash and bank transfer for a food truck or market stall

Common objections from mobile vendors, answered

"My customers don't have crypto."

Some do not; a growing share do, and they skew towards the people a truck or stall wants most — younger, urban, travelling, paid in dollars from abroad. This is an additional rail with zero hardware cost, not a bet on replacing cash. The sign on the board costs a sheet of paper; every sale it captures skips the fee line, the reader and the cash box. Start with it as a third option and let the report tell you what share it takes.

"I don't want to hold something that moves in price."

You do not have to. Auto-convert settles every sale as USDC or USDT, a dollar stablecoin, whatever the customer paid with. What lands in your wallet is dollars, and how you move them from there — to an exchange, to a card, to a bank — is a separate decision that no processor makes for you. The detail is in avoiding 3% card fees with stablecoin payments.

"What if the customer's phone has no signal either?"

Then neither rail works, exactly as today with a card reader — except that a phone with one bar of 4G is a far more common object at a festival than a Bluetooth dongle with a charged battery. The QR itself needs no connection to display; the customer's wallet needs to reach the network to send, and your phone to see the confirmation. In practice a queue where every customer already has a working phone in hand is the best-connected queue you have.

"Isn't managing a wallet more work than a reader?"

Set it up once — a wallet address, 2FA, a PIN per helper — and the day-to-day is a phone showing a QR. There is nothing to charge, pair or replace, and there is one thing to protect: your wallet's keys, which is the same responsibility you already carry for a cash box, with far better tools. Payzum's own security stack — 2FA, signed webhooks, encrypted secrets and a full audit log — covers the account; the money itself is never in Payzum's hands to lose.