Merchant Lock
Restrict to specific vendors: "AWS only" or "Hilton only."
Plan a virtual card per employee, vendor, or campaign. Confirm issuer, network, eligibility, controls, funding, transaction events, and wallet support before rollout.
Without on-demand issuance, five people share one corporate card. Procurement slows. Reimbursements stack up.
Shared cards have no per-user limits, no merchant restrictions, and no transaction-level budget enforcement.
Matching receipts to statements drains time from finance every month-end, especially when receipts are missing.
Budget owners find out about overages when the statement closes. By then it is too late.
International purchases on domestic cards trigger dynamic conversion fees and unfavorable rates.
Allocating shared card transactions across departments and projects is manual work every month.
Create a card per employee, vendor, or ad campaign. Set budgets, merchant locks, and expiry dates. See every transaction live.
Submit an approved card request and track its requested, under-review, active, frozen, or closed status.
Set spending limits by amount, frequency, merchant category, or date range. Declines happen at the point of sale, not after.
See every auth, decline, and settlement as it happens. Webhooks and dashboard, real time.
International purchases settle at competitive rates. No dynamic conversion fee surprises.
Each card maps to a team, project, or vendor. Month-end close gets simpler.
Lock a card to specific vendors or merchant categories. "AWS only" or "travel only."
Restrict to specific vendors: "AWS only" or "Hilton only."
Hard daily, weekly, or monthly spend limits. Declines happen at the register.
Cards self-expire after a date you set. Perfect for one-off trips.
Offer wallet provisioning only where the approved issuer, network, device, and program support it.
Card programs
A virtual card is a card number with a policy attached to it. The number is real to the merchant and disposable to the buyer, which is the whole point: the control sits on the credential rather than on the person holding it. A limit, a merchant category, a single use, an expiry measured in days. The tradeoff is that everything downstream of the number then has to cope with a credential designed to stop working. Receipts, subscriptions, a refund to a card that has since closed, and a finance team that reconciles by the last four digits when the last four change every time.
Single use and recurring are opposite requirements, and the networks have started saying so in the response. Since October 2023 Mastercard has returned a merchant advice code identifying a consumer single-use virtual card number, code 41, alongside code 40 for a consumer non-reloadable prepaid card. It arrives on approvals as well as declines, so a merchant that reads it learns at the first successful payment that the credential should not be filed for later. Those two codes describe consumer products. A commercial card issued for spend management can present the same way to a merchant without necessarily carrying an equivalent flag, so the sequence runs: payment succeeds, subscription created, credential filed, and the second month fails on a number built to work once.
Consider a team of 40 people issued one card each with a $2,000 monthly limit. That is $80,000 of authorized exposure against a real spend of, say, $18,000, and the gap is the number a finance lead gets asked about. Cut every limit to $600 and exposure falls to $24,000, but say six of the forty then hit a ceiling mid-purchase in the first month, each producing a ticket and a raise request while somebody waits at a checkout. The per-person version costs more to set up and lands better: last quarter of spend per cardholder plus a margin, which for most of the forty is well under $600 and for three of them is well over $2,000.
Most card programs target spend management. Gruv adds partner-issued cards as a payout destination, alongside bank transfer, wallet, and crypto.
Bring payout records into Gruv through CSV or structured imports. Match recipients, check amounts and references, then r
Move eligible approved payouts into execution with a configured workflow. Follow payment status and keep holds or invali
Give payees a place to update bank details and follow their payment status. Keep account changes separate from your team
Next step
Tell us what you are trying to do, where it needs to work, and how your team handles it today.
Contact the team