Launching a card program with Increase
Increase is an issuer processor that provides direct access to Visa for issuing cards. Your card program runs on the same infrastructure and through the same accounts enabled for ACH, wires, Real-Time Payments, and other payment rails. Increase is a single technology stack for all money movement.
We design our APIs with No Abstractions. This means you see the actual authorization fields, settlement entries, and lifecycle events that Visa sends rather than a summarized interpretation of them. For teams building sophisticated card products, this visibility matters. High-fidelity data from the card network lets you quickly debug issues, build precise reconciliation logic, and handle edge cases that abstracted APIs often obscure.
The lifecycle of a card transaction
When a cardholder uses their card to make a payment, a series of messages travel between the merchant, the card network, and the issuer. Unlike other payment rails like an ACH transfer or wire transfer, card payments do not move through a single sequence of statuses. Instead, a Card Payment is composed of different entries that correspond to the messages sent over the network.
Most payments start with an authorization. At this stage, no money moves. The authorization is a message from the merchant that puts a hold on the amount before settling with the card networks later. Increase creates a pending transaction for each authorization to model this hold on the account balance.
After authorization, several things can happen. The merchant might increment the authorization (common for tips at restaurants), reverse it partially or fully (common when checking out of a hotel), or settle it for the final amount. Each of these events appears as a separate entry on the card payment object, and Increase sends webhooks for each one.
Understanding this lifecycle matters because different entries have different implications. An authorization that expires after seven days behaves differently than one reversed by the merchant. A settlement can arrive for a different amount than the original authorization. Seeing these details lets you build accurate reconciliation and provide clear transaction histories to your users.
Sitting in the authorization flow
With Increase, your system can sit in the authorization flow of a card transaction. Rather than receiving a notification after a transaction has already been approved or declined, you can receive the authorization request directly and respond with your own decision.
This works through our Real-Time Decisions API. When a card is used, Increase creates a Real-Time Decision object and sends you a webhook containing the authorization request. Your server has a few seconds to evaluate the transaction and respond with an approval or decline.
The webhook payload includes the fields you need to make a decision: the amount, the merchant category code (MCC), the merchant name and location, and any Address Verification System (AVS) results. You can check these against your own rules—balance limits, category restrictions, geographic controls—and return your verdict.
Building customized spend controls
Spend controls are rules that govern when and how a card can be used. Because you receive the full authorization request, you can build controls that match your precise product requirements.
For example, you can build controls around what merchant category code (MCC) can accept payment from the cards you issue. An expense management platform might allow MCC 5812 (restaurants) but decline MCC 7995 (gambling). A fleet card program might only authorize purchases at fuel stations. You define the logic; Increase routes the decision to your server.
Beyond category restrictions, you can implement velocity limits (no more than a certain amount per day or per transaction), geographic restrictions based on merchant location, time-of-day rules, or checks against AVS codes to validate billing addresses. Because your server handles the decision, you can evolve these rules as your product matures without waiting for new features from a processor.
Network-level purchase data
Some transactions carry enhanced data beyond the basic clearing fields. This network-level purchase data, sometimes called Level 2 or Level 3 data, includes details about what was actually purchased. A rental car transaction might include pickup and return dates. An airline purchase might include flight details and passenger information. Invoice-level data might include tax amounts, shipping costs, and discounts.
For expense management and corporate card programs, this data enables automatic categorization, or policy enforcement without requiring employees to submit receipts. Increase exposes supplemental purchase data through the API when merchants provide it.
Each authorization also includes the raw ISO 8583 message fields. ISO 8583 is the standard message format used by payment networks worldwide.
Card types and BINs
Increase supports issuing Visa cards on dedicated BIN ranges. A BIN (bank identification number) is the prefix on card numbers that identifies the issuer and card type. We offer commercial, credit, and debit BINs depending on your program’s needs.
You can issue both single-use and multi-use cards. Single-use cards are generated for a specific transaction and cannot be reused, which is useful for one-time vendor payments or reducing fraud exposure. Multi-use cards persist across transactions.
Virtual and physical cards
Through Increase, you can issue both virtual and physical cards. Virtual cards can be issued instantly through the API. They work for online purchases and can be added to digital wallets like Apple Pay and Google Pay. This gives your users immediate utility the moment they sign up.
Physical cards require coordination with a card manufacturer. Increase works with Idemia, one of the world’s largest fulfillment providers, so you can ship customized physical cards with your own branding, including custom carriers and high-quality graphics printing. Both virtual and physical cards can share the same underlying account and enforce the customized controls you build.
Disputes
An unavoidable part of running a card program is handling disputes between merchants and cardholders. A dispute is essentially a structured back-and-forth, run by the issuer under the card network’s rules, that continues until the cardholder’s claim is either accepted or denied.
Increase’s Card Disputes API models the rules for each dispute category the card network exposes. You start a dispute by providing the disputed transaction, the amount, and relevant evidence. Increase reviews the submission, then sends it to the merchant through the card network. The merchant can respond, you can reply, and this continues until resolution. The API tracks Network Events and User Submissions throughout the lifecycle of the dispute, so you can build a clear dispute experience for your cardholders.
HSA/FSA and Fleet programs
Certain industries require access to specialized data, and benefit from Increase’s commitment to passing through this type of data with high fidelity. For example, Health Savings Account (HSA) and Flexible Spending Account (FSA) cards need to validate purchases against IRS-eligible healthcare expenses. Fleet cards need to capture fuel type, odometer readings, and driver identification at the pump.
For HSA/FSA programs, authorization messages can include healthcare-specific amount fields—clinic, dental, prescription, and vision amounts—that let you verify eligible purchases in real time. You can approve transactions at merchants with Inventory Information Approval System (IIAS) rules, enforce MCC restrictions for healthcare providers, and auto-substantiate claims without requiring manual receipt submission. The raw authorization data gives you what you need to comply with IRS requirements programmatically.
For fleet programs, Increase exposes fuel confirmation messages that include the actual amount dispensed, which often differs from the initial authorization hold. You can also receive driver prompts, vehicle IDs, and odometer readings when merchants provide them. When combined with MCC-based spend controls, this enables fleet programs to build cards that authorize only at fuel merchants, capture per-gallon data for expense tracking, and prevent misuse at non-fuel locations.
Direct access to the network messages means you can build compliant, full-featured programs without working around your processor’s data model.
Unified money movement
At Increase, cards are issued from the same Accounts you use for ACH, wires, Real-Time Payments, and other payment rails. A dollar in your account is available for card transactions, wire transfers, or ACH debits without needing to move funds between separate pools or manage fragmented liquidity.
This also means a single ledger for all money movement. For platforms building financial products, this consistency reduces your reconciliation burden and drives efficiencies for your treasury operations.
Unified accounts and money movement are what make Increase’s card issuing stack stand out. You get access to a single, robust infrastructure for banking, cards, and every other payment rail in one place.
Getting started
Launching a card program involves determining your preferred compliance model and working directly with one of our BIN sponsors. On the technical side, you’ll need to open accounts, build your authorization logic, and integrate card issuance into your product. Depending on your use case, we can get you off the ground in just a few weeks.
We offer a robust sandbox environment to simulate authorizations, test webhook handling, and verify edge cases before going live. Our API documentation covers all of the technical details.
If you are building a card program and want access to powerful infrastructure that gives you speed, precision and control, we’d love to chat. Drop us a note at hello@increase.com.