A Draw Is Not a Purchase: Why BNPL Configuration Scope Belongs at the Draw Level

BNPL purchases record transactions. Draws set loan terms.

A draw can carry its own rate, amortization, and lifecycle, so rate and repayment logic belong at draw level.

A Purchase Is the Transaction. A Draw Is the Thing That Converts.

In Peach's product model, a card purchase creates the transaction record. A draw is the card-program unit that can convert into an installment plan independently.

Each draw runs its own conversion lifecycle, separate from the parent purchase and separate from sibling draws on the same card. When you work with card-to-installment behavior, you're working at the draw level, one conversion event at a time.

That distinction isn't a vocabulary call. It is the boundary that keeps transaction records separate from the draw-level lifecycle that can become repayment structure.

A purchase records a transaction. A draw converts into a repayment structure. Flip the two and you've mislocated the foundation before you reach a single downstream concept.

What a Draw Actually Does: Its Own Rate, Its Own Identity

Peach assigns each line-of-credit draw its own identifier.

Per-draw IDs make independence structural, not conceptual. Without one, a servicing system can't separate a payoff on one draw from a rate change on another on the same account. The identifier is what makes separate tracking real.

Each draw can be amortized or non-amortized. Two distinct repayment structures. Amortized means payments reduce principal on a defined schedule, so you know how much goes to principal and when the draw pays off. Non-amortized means no fixed reduction schedule, so principal doesn't step down on a timetable.

A lending ops team configuring a two-draw facility sets each draw independently. One draw amortized, the other not. Standard rate on one, promotional rate on the other.

They belong to the draw.

When a promotional period applies to a draw, Peach can track that draw separately.

Peach's technical reference says each draw has its own identifier, like a sub-loan.

That's what makes "independently" load-bearing, not decoration.

What the Purchase Does Instead: Balance Effects and Dispute Workflows

Launch a cash-back rewards card on Peach and you need reward credits to reduce the cardholder's balance. That's not a workaround. It's a typed transaction.

Peach defines three purchase types within a line of credit. Regular, cashBack, and refund. Each one determines what happens to the borrower's principal balance when the purchase posts.

A regular purchase increases principal. That's the standard spend event.

A cashBack purchase reduces it. A refund purchase also reduces it.

When your rewards program credits a cardholder, that credit posts as a cashBack purchase and the balance falls accordingly. No custom balance adjustment. The type carries the work.

A typed purchase moves the balance in a defined direction. Which way is already in the type.

Which means purchases have real work to do, just not conversion work.

A contested transaction shows this from another angle. When a borrower on your portfolio disputes a purchase, that dispute runs through a first-class workflow built into the platform. Not a manual exception path. Not a side process someone manages outside the system. The resolution path is designed into Peach.

Beyond individual purchases, Peach supports sub-lines within a line of credit. A sub-line can carry its own interest rate and its own grace period, independent of any other sub-line on the same account. A borrower's credit facility can have sub-lines priced and structured differently from each other.

That per-sub-line independence mirrors what draws do on the conversion side, each unit holding its own rate and identifier. But the jobs aren't the same.

Purchases own the balance ledger. That means tracking what the borrower owes, which direction the balance should move, and whether a transaction is contested. Draws own the conversion lifecycle, where a unit becomes a repayment structure.

Nothing on the purchase side converts. Conversion doesn't enter it.

Where Draws Live: BNPL Construct Types and the Cards That Carry Them

Most teams approaching BNPL carry a single mental model: a customer hits checkout, chooses installments, and a repayment plan fires. That picture holds for one construct type. Peach supports four, and which one you're building on determines which event creates a draw, when that draw exists to be configured, and what rates and terms are available. Picking the wrong construct type doesn't just mean picking the wrong name. It means your trigger event is wrong before the first draw is ever configured.

That's the fork that matters. Not the construct names as labels, but what each one means for when draw creation fires.

Pre-purchase loads funds onto a BNPL virtual card before the customer spends. That loan doesn't tie to the card-load event; it ties to a purchase made with that card afterward. Draw creation follows the downstream purchase, not the moment the card was funded.

Point-of-sale works at a different moment. A POS transaction becomes a BNPL loan at the moment of purchase, whether online or in store and with or without interest. Nothing needs to happen after the fact. Draw creation fires with the transaction.

Post-purchase debit inverts the timing again. Existing debit card purchases are converted into BNPL loans after the spending has already cleared. Cardholders transacted first; the installment structure arrives after. An existing spend converts, not a pending one.

Credit cards with BNPL sit differently still. A credit card can convert select transactions into installment loans, not all of them and not automatically. The important point is narrower: select transactions can convert into BNPL loans, and every transaction does not convert automatically.

Four constructs, four different moments where a transaction can become a loan.

A draw doesn't exist until the right event fires for its construct type, and which event that is isn't uniform across the four. Your product team's first question isn't which construct is simplest to stand up: it's which event in your user journey triggers draw creation, and that's what a construct type actually names. Once you have the answer, you know which construct you're building on.

Peach supports credit cards, charge cards, virtual cards, and BNPL virtual cards. Those aren't interchangeable instruments.

The pre-purchase construct uses a BNPL virtual card: funds load onto it before any spending happens, and the loan ties to a downstream purchase. A standard credit card or charge card operates from a different foundation, without pre-loaded funds; a credit card carries a revolving line that select transactions can be converted off of. Those are different loan-attachment models, and which one you're building on shapes what draw creation means in your program. Knowing which construct you're configuring tells you which card type belongs in it; treating them as equivalent means reaching for draw-level configuration before you've identified what you're actually building on.

Peach participates in Visa Ready for BNPL and Mastercard Installments partner programs. If your team is evaluating what those relationships mean for a build, the framing is worth holding precisely.

Participating in a partner program isn't the same as having a direct card-network integration. Peach doesn't have one.

Describing Peach as "connected to Visa" implies a direct technical integration that doesn't exist. Peach participates in Visa Ready for BNPL and supports card-network programs without claiming a direct technical connection.

Your construct type determines your trigger event. Once you know your trigger event, you know when a draw comes into existence and what's configurable at that moment.

Pre-purchase, point-of-sale, and post-purchase conversion each place loan creation at a different moment. A POS transaction becomes the loan at the moment of purchase. Post-purchase conversion applies after spending has cleared. Each timing changes when draws exist, what you can set at creation, and how repayment terms can be structured.

Construct type is the first configuration decision, not a categorization step you can settle later. Draw-level parameters, rates, terms, what's modifiable and when, all follow from which trigger event the construct uses. Misread which construct you're running and you're configuring draws against an event that never fires. That mistake tends to surface after the rate logic is built, not before.

When One Purchase Has Multiple Captures: Where Purchase-Level Scoping Breaks

One purchase, one installment plan. That works when a merchant charges the full transaction amount at once.

A travel fintech hits the edge when their merchant processes lodging, flights, and car rental as separate charges against one booking reference. Lodging posts when the stay closes. The flight charge arrives separately. Car rental settles when the keys come back. Each of those is a capture event, a charge that posts to the card after the original purchase, arriving at its own time. One booking, three captures.

Standard installment loans lock to the booking total and can't handle what follows. When the next charge arrives, there's no home for it in the structure.

Retail hits the same wall: orders with items shipping separately arrive as multiple charges. Traditional installment loans don't handle the multi-capture pattern. Configuration can't bridge that gap; the product shape doesn't reach it.

Peach's Multi-Capture Installment Loan is a distinct product shape for merchants who don't process an entire transaction at once. It accommodates multiple items within one loan construct and uses configurable rules to govern how each arriving capture modifies repayment terms. When lodging posts, those rules run and the schedule adjusts. As the flight charge follows, they run again.

Scope installment conversion at the purchase level and you're building a payment schedule against an amount that hasn't fully arrived. Each charge that posts later finds a model that was locked before it existed. Multi-Capture Installment Loan keeps the schedule tied to what's been charged, advancing with each capture as it posts.

Scope at the Draw Level: What This Means When You're Configuring or Already Live

Add a BNPL installment overlay on top of a live card product and the first question is usually about code. How long does the deploy take, who writes it, what else breaks?

On Peach, that question has a different answer.

New loan types launch as configurations, not schema refactors. Configuration changes can go live without a code deploy, though not every variable is changeable on a live portfolio. For operators standing up a new product type, that speed difference is real, but configuration space is widest when you're building fresh and narrows once a portfolio is live. Account for that before launch, not during it.

Peach's Adaptive Core is asset-agnostic across installment, BNPL, line of credit, revolving, and other product types. Draw-level independence isn't a card-program exception; it's how the platform is built. Each draw carries its own rate, amortization structure, and lifecycle. When you add a BNPL overlay, you're not layering on top of the purchase. The draw configuration runs on its own lifecycle.

Get the framing wrong early, scope to the purchase instead of the draw, and the mismatch surfaces after the rate logic is built. Not during onboarding. After.

‍