Every funding event needs a new card number

swype

CARD TYPES & ISSUANCE • FUNDING MODEL

Are Swype cards reloadable?

No — every Swype card is single-load and non-reloadable. Here's what that means for how you design funding flows for your end users.

AUDIENCE

B2B Clients

FUNDING MODEL

Single-load only

TOP-UP FLOW

Not supported

Summary: all Swype cards are non-reloadable. Once the available balance is used, the card cannot be topped up or reused. Additional funds require issuing a new card — there's no reload API or top-up endpoint to build against.

①

What this means for your funding model

Each card has exactly one lifecycle: issue, fund once, spend down, done. There's no reload mechanism at any point in that lifecycle:

●

No top-up or reload endpoint exists in the API — don't design a flow expecting one

●

A depleted card cannot be revived — it stays at zero permanently

●

Additional funds for the same end user means issuing a new card, not adding to the existing one

②

Designing around single-load

If your use case involves recurring or ongoing funding for the same end user, plan for repeated issuance rather than a reload cycle. In practice that affects:

●

UX copy — tell end users they're getting a new card, not a refill, to avoid support tickets when the old card number stops working

●

Issuance cadence — if users need funds monthly, your integration should issue a fresh card each cycle

●

Wallet provisioning — if cards are added to Apple Pay or Google Pay, end users will need to re-provision each new card issued

●

Reporting — track spend per card issuance, not per end user balance, since each card is its own funding event

Important

Don't advertise "reload" or "top-up" language to your end users — it sets an expectation the card program can't fulfill and will generate avoidable support volume on both sides.

Building a recurring funding flow?

Talk to us about issuance cadence and API patterns before you commit to a UX design.

Contact Support →