The Checkout Business Account was Checkout's most significant product pivot in recent years – a structural shift from pure payment processing towards a financial operating system for merchants.
Historically, funds arrived on platform after a payment was processed, became briefly visible in a currency account, and were then swept out to an external bank. Internal data showed that in 2023, $64 billion flowed through Checkout's currency accounts – and $63 billion was swept straight out.
The opportunity was to change that relationship. Instead of treating balances as temporary holding areas, the Business Account would give merchants a financial home inside Checkout – a place to hold, move, access, spend, and monitor funds already flowing through the platform.
For merchants, this meant greater visibility and control across balances, settlements, transfers, cards, FX, and future financial capabilities. For Checkout, it created a way to extend beyond payment processing into a broader financial operating system for merchants.
The Business Account wasn't a single product. It was a unifying layer – a coherent financial home that brought together capabilities that had previously existed in isolation or not at all: Balances, Transfers, Standard Settlements, Accelerated Settlements, Corporate Cards, Funds Pooling, FX, and Yield. The design challenge was making these feel like one integrated account experience, rather than a collection of separate tools bolted onto the Dashboard. That meant defining a container modular enough to scale, while keeping the underlying model coherent as new capabilities were added.
As Director of Product Design, I owned the end-to-end experience – from early discovery and architecture decisions through to shipped features across every product within the Business Account umbrella. I partnered closely with product leadership to shape the roadmap, sequence capability releases, and take the Business Account and its features from Beta through to general availability.
Checkout had historically operated as a pass-through. When merchants processed payments, funds landed in currency accounts and were quickly swept to an external bank account. Merchants did not really think of those accounts as something they could operate from. Checkout was the place money arrived briefly, before it moved somewhere more useful.
That worked while Checkout's role was mainly payment processing. The Dashboard helped merchants understand what had happened, when they would be paid, and how to reconcile activity afterwards.
But Checkout sat in a much more powerful position in the payment flow. As merchants scaled, the funds already moving through Checkout could become operational. They could be held across currencies, allocated across entities, used to fund payouts and cards, moved for FX, and managed as part of day-to-day treasury workflows.
The Business Account was the proposal for turning that opportunity into a product.
Above: Originally introduced as a stopgap, the Balances page provided basic visibility but failed to support how finance teams manage, reconcile, and move money.
The existing Balances page had done the job it was originally asked to do. It gave merchants a live view of balances so card payouts and issuing could scale. But it had not been designed as a financial home, and that showed in the experience.
We spoke to treasury managers, finance leads, finance operations managers and VPs of Finance across enterprise merchants. That included BNPL providers, remittance businesses, iGaming platforms and multi-entity retail groups. The same problems kept coming up, and they became more painful as merchants grew.
The problem had moved beyond "where is my payout?" It had become a broader operational question. What funds do I have, where are they held, what state are they in, when can I use them, and how do I move them without losing control?
The existing model could not answer those questions coherently. Funds technically existed inside Checkout, but they did not behave like an account merchants could operate from. Balances, settlements, transfers, cards and reports existed as related surfaces, but not as one financial system.
That created a scalability problem as well as a usability problem. Every new capability, from FX to cards to acceleration to yield, risked becoming another financial tool layered onto the Dashboard rather than part of a shared operating model.
The reframing insight was that merchants would be willing to keep funds on platform if Checkout could give them the transparency and control they expected from a bank, with the added advantage of real-time payment data.
The opportunity was not to copy banking. It was to be better in the specific place where Checkout had a structural advantage, by turning payment data, balances, settlement timing and money movement into a financial operating system merchants could trust and act from.
The Business Account was not a single feature. It was a new product category for Checkout, sitting on top of payment processing and turning the flow of funds into something merchants could operate from.
At the same time, several capabilities were starting to emerge around it. Balances, settlements, FX, cards and acceleration were all connected, but without a clear product model they could easily have become a collection of financial tools sitting next to each other in the Dashboard. That would have made the account harder to understand, harder to scale and harder for merchants to trust.
We needed a model that matched how merchants actually think about money across accounts, settlements and cashflow, rather than one based on how internal teams or financial products happened to be organised.
The first job was to make the Business Account a credible financial home, giving merchants a clear way to see funds, understand their position, move money with confidence and trust that the account behaved predictably.
Once that foundation was in place, Checkout could extend into capabilities with standalone value, such as earlier access to funds, yield, cards and future credit products.
Checkout had a structural advantage because it already sat inside the payment flow. The question was how to turn that position into a product without creating disconnected tools.
The answer was a shared operating model built around five verbs.
Store. Move. Borrow. Grow. Monitor.
Store was about making funds visible and trustworthy. Balances, Funds Pooling and Top-ups belonged here because they defined where money lived, what state it was in and when it could be used. This had to come first because merchants cannot move money confidently if they do not trust the balance they are moving it from.
Move was about putting funds to work. Transfers, Settlements and Corporate Cards all changed the position of funds, either within the Business Account or out to external destinations. This depended on Store being clear, because every movement needed a visible source, destination, currency and outcome before a merchant could commit to it.
Borrow was about accessing funds earlier. Accelerated Settlements brought forward money merchants were already due to receive, without changing the underlying settlement model. We deliberately held this back until settlement flows were legible. In testing, merchants would not use acceleration confidently if they did not understand what was being brought forward, what remained scheduled and how the standard settlement flow worked.
Grow was about making stored funds work harder while they remained on platform. Yield only made sense once merchants were comfortable leaving funds inside the Business Account. The account first had to feel trustworthy as a place to hold and manage money before it could credibly offer a return on those funds.
Monitor ran through the whole model. It was not a separate product area in the same way as Store, Move, Borrow and Grow. It was the layer that made the rest of the system credible. Merchants needed to see the balance, but they also needed to understand what changed, why it changed and where to investigate when something did not look right.
This sequencing gave the product a clearer shape. Merchants had a mental model they could understand without training. The interface hierarchy reflected how money was actually used, not just how it was stored. New capabilities could extend the same account structures, balance states and ledger behaviours instead of creating parallel systems.
That was the strategic value of the model. It allowed the Business Account to grow in capability without losing clarity, so new financial products could be added to the same underlying system rather than fragmenting the Dashboard over time.
The Business Account was built around the observation that merchants do not manage money as a single balance.
They operate across legal entities, currencies, operational teams and settlement flows, often at the same time. Existing payment platforms tended to flatten that complexity into a single merchant account, which left finance teams rebuilding their real operating structure through exports, spreadsheets and external treasury tools.
The challenge was not just to expose balances. It was to create a financial model that reflected how merchants actually organise and operate money.
The hierarchy that emerged had three levels.
Client was the top-level view across the whole business group.
Entity represented a regional or operational unit, such as UK Ltd or SAS.
Sub-account represented a currency specific account within an entity, with its own balance states and transaction history.
This hierarchy became the foundation of the system. Funds were no longer treated as one merchant balance. They were held in specific operational contexts, tied to entities, currencies and sub-accounts that could be understood, permissioned and acted on independently.
The earliest work didn't happen in design tools. Before we designed screens, we ran a structured sprint with Product, Design, Commercial and Engineering to define the underlying architecture of the Business Account. The aim was to understand the model before committing to an interface.
The sprint focused on the core financial tasks merchants needed to perform, including inflows, outflows, holding funds and moving money across currencies. It also helped us map the assumptions we were making, identify what we did not yet understand, and compare different ways a bank-like account layer could fit inside the existing Dashboard.
Above: Mapping core bank-like tasks across funds inflow, holding funds and funds outflow, helping the team move from feature ideas into the account model.
That gave us a clearer way to separate the jobs the Business Account needed to support. Some work was about money entering the system. Some was about holding and understanding funds. Some was about moving money out or moving it between accounts. Mapping those tasks first helped avoid designing around a list of features before we understood the shape of the financial system underneath.
Above: Exploration of enterprise account structures, mapping Client, Entity and Sub-account relationships across regions and currencies.
Language quickly became part of the architecture, not just a content problem. Balance labels such as Available, Pending, Operational, Collateral and Payable were not consistently understood. Defining those terms became part of defining the operating model, because merchants make financial decisions based on what they believe those states mean.
The core shift was from a reporting-first view to an account-first view.
The old model showed merchants what had happened. The new model needed to give them a financial home they could act from. That was not a visual change. It was an information architecture change that affected every part of the product.
Balances, settlements and transfers could no longer sit as loosely connected surfaces. They needed to be organised around where funds lived, how they moved and what state they were in.
Above: Sprint work mapping existing reporting-focused structures against a proposed account model, exploring how balances, settlements and transfers could be reorganised into a financial home merchants could act from.
We considered keeping the existing consolidated view and rejected it.
It may have worked for smaller merchants, but it would not have supported enterprise clients. Larger businesses needed access segregation, with different users operating across regions, entities and teams while only seeing the parts of the business relevant to them.
The three-tier structure also gave the product room to scale. New capabilities could build on the same account hierarchy instead of creating separate financial models as the platform evolved.
Above: Early model showing how Client, Entity, Business Account and Sub-accounts relate to each other, defining how accounts are owned, grouped and scaled across the system.
The design needed to make the structure understandable without collapsing it into something too simple to be true.
Accounts had to scale across entities, support multiple currencies and remain coherent as new capabilities were introduced. Funds could not be treated as one flat surface. They had to be partitioned in a way that reflected real organisational structures, while still being easy enough to navigate and operate.
The challenge was allowing merchants to move between aggregated and operational views of money without losing the relationship between them.
Above: Working model of the Business Account interface, mapping how balance states, sub-accounts and related product areas such as cards, transactions and activity were organised within the account.
This is where the structure became tangible. The Business Account stopped behaving like a reporting surface and started behaving like a financial operating system, where balances, movement, settlement, spend and future capabilities were anchored to where funds actually lived.
The interface supported multiple levels of aggregation. A Client view gave a consolidated view across entities. An Entity view grouped sub-accounts within a specific part of the business. A Sub-account view exposed the operational detail beneath it.
Each level reflected the same financial system at a different level of abstraction. Merchants could move from a consolidated view down into account detail without changing mental models or losing the relationship between funds, entities and movement.
This structure became the foundation for everything that followed, from Balances and Settlements through to Cards, Acceleration and future Yield capabilities.
Rather than layering new financial products alongside the Business Account, new capabilities could extend the same operational and ledger model over time. That allowed the platform to scale more like a financial operating system than a collection of disconnected tools.
The design
This is the point where the work moved from structure into behaviour.
The strategy defined what the Business Account needed to become. The account architecture defined how funds, entities and sub-accounts related to each other. The design work turned that into an experience merchants could understand, trust and act from.
The product was built around a clear financial model. Funds live in sub-accounts, each tied to an entity and currency. Those funds move through defined states such as Pending, Available and Payable, and are shaped by settlement timing, reserves and ledger activity.
The challenge was not to hide that complexity. It was to make it legible enough for merchants to make decisions with confidence. Finance teams needed to understand where funds were held, what state those funds were in, how they would change over time and what actions were available at each point.
That meant designing the Business Account as one connected system, not a set of isolated features. Viewing balances, transferring funds, spending on cards, accelerating settlements and checking activity all needed to follow the same underlying rules, so merchants could learn the model once and apply it across different contexts.
The sections that follow show how that model was expressed across the product.
Store makes funds visible and trustworthy.
Move helps merchants put funds to work.
Borrow brings forward access to funds without changing the settlement model.
Grow creates value from funds held on platform.
Monitor allows merchants to understand what changed and why.
Store – making balances trustworthy
Store defines how funds are held and understood within the Business Account. Before funds can be moved or acted on, merchants need a clear and reliable view of their position.
Everything else in the product depends on this. If a balance is unclear, or behaves in a way that does not match expectations, nothing built on top of it gets used.
Funds are not a single number. They exist across sub-accounts, in different currencies, and move between balance states over time. The design needed to make that model understandable without turning the interface into a reporting tool.
Balances
Each sub-account holds multiple balance types that represent different states of funds. Available reflects funds that can be used immediately or settled. Pending reflects incoming funds that have not yet cleared. Payable represents funds reserved from Available for outgoing payments that are in transit. Operational provides backup funds for outbound payments when Available is insufficient. Collateral represents funds held for risk and reserve requirements.
These are not separate totals. They are part of a lifecycle where funds move between states over time. The design needed to make those states understandable without overwhelming the interface or forcing merchants into reconciliation workflows just to understand their position.
Early exploration focused on how these states could be represented without collapsing them into a single total. Pending, Available, and Payable needed to remain distinct, while still reading as part of the same system.
Above: Early exploration testing how Pending, Available, and Payable could be represented without collapsing them into a single total.
This became a question of hierarchy – what to prioritise, what to surface, and how to keep the model legible at a glance.
The interface prioritises Available at the entity level, as it represents what can be acted on. Pending is surfaced alongside it to provide context on what will become available. The remaining balance types remain accessible, but do not compete for attention. At the entity level, balances are aggregated across sub-accounts to provide a consolidated view.
Above: Entity-level view showing consolidated Available balance, sub-account summaries, and Available balance over time.
Sub-accounts are surfaced as summaries, allowing merchants to understand how funds are distributed across entities and currencies without losing the top-level position.
The chart is intentionally lightweight. It shows how Available balance has changed across the selected period, providing a directional view rather than a detailed breakdown. The table below supports this by showing opening available, net change, and closing available for each day.
The same view can be switched to a tabular format.
Above: Table view exposing sub-accounts alongside all balance types, while retaining the Available balance over time view below.
This view exposes the full balance model. Available, Pending, Payable, Operational, and Collateral are shown side by side, making it easier to compare how funds are partitioned across sub-accounts and states.
Detailed movement and investigation sits in Monitor. Store focuses on the current and future funds position – what is available, what is pending, where funds are held, and when they can be used.
Pending funds
Pending reflects funds that have arrived but not yet cleared into Available balance. Knowing a total exists is not the same as knowing when it can be used – and without that, finance teams are left to plan around a number that could become spendable in hours or in days.
This was one of the clearest gaps in the original Balances page. There was no way to see when Pending funds would become Available, which blocked decisions around payouts, FX moves, and supplier payments. Teams fell back on manually checking balances each day just to confirm an account would stay positive.
Above: Balances overview showing pending funds by availability date, sub-account and currency.
Selecting a date breaks the total down by currency and sub-account, tracing it back to the processing periods behind it. This turns Pending from a static number into a forecastable part of the account's position, answered directly rather than reconstructed from settlement schedules after the fact.
Funds pooling
Separating funds across sub-accounts introduces a liquidity constraint. A sub-account can lack sufficient Available balance to complete an action, even when sufficient funds exist elsewhere within the same entity.
Funds pooling allows the system to cover these shortfalls automatically by drawing from other sub-accounts within the entity. By default, this uses Available balances, and in some configurations it can also draw from Pending balances.
The challenge was making that behaviour understandable. Automatic movement of funds can feel unpredictable if it is hidden, and framing it as an error suggests failure when the system is actually working as intended.
The design made pooling visible at the moments users needed to understand it. Low balance notifications explained when an account was approaching its threshold and set the expectation that funds could be rebalanced from another account if needed.
Above: Notification emails explaining when a balance has fallen below its threshold and when funds have been automatically moved to cover a shortfall.
Above: Pooling event showing funds drawn from another sub-account within the entity to complete an action, making cross-account liquidity visible.
Pooled funds appeared as a labelled movement alongside other transfers, so users could see that the system had moved money automatically and understand it as part of normal account activity.
This positioned pooling as part of the normal behaviour of the account, rather than an exception. Users could understand why money moved and how it helped keep the account usable.
Above: Transfers activity table showing funds pooling as a labelled movement within account activity.
Top-ups
Top-ups allow funds to be added into a sub-account, increasing the Available or Operational balance.
While balances describe what funds exist, top-ups define how funds enter the system. This makes them part of the same model. Funds do not appear globally. They are always added into a specific sub-account, in a specific currency, and into a defined balance state.
The interaction itself is intentionally simple, but the behaviour behind it is precise. Adding funds requires selecting both a source account and a destination sub-account, along with the amount and reference.
Above: Initial screen of the top-up flow showing source bank account, destination sub-account, and amount.
Above: Merchants choose a local or international bank transfer, which determines the bank details shared for payment.
Above: Top-up details showing source bank account, destination sub-account, and reference.
Funds are not transferred instantly within the interface. Instead, the system generates the bank details and reference required to complete the transfer externally. This ensures that funds are correctly attributed when they arrive.
The reference plays a critical role. It determines how the incoming funds are allocated, including which balance type they are assigned to. For example, funds can be directed to Available or Operational balance depending on how they are configured.
This keeps the behaviour consistent with the balance model. Funds do not arrive ambiguously – they are explicitly placed into a known sub-account and state.
Top-ups also appear in the same surfaces as other balance changes. Once processed, they are reflected in balance activity and contribute to changes in Available balance over time.
This ensures continuity across the system. Whether funds originate from payments, transfers, or top-ups, they are represented in the same way, within the same model.
Move – making movement predictable
If Store defines where funds live, Move defines how funds travel through and out of the Business Account.
Funds do not sit in one place. They move between sub-accounts, across currencies, and out to external destinations. Each movement changes both the position and state of funds.
As soon as funds start moving, it becomes harder to understand what has changed. A single action can span multiple sub-accounts, currencies, and balance states, making it difficult to follow where funds have gone and why.
The design extends the model established in Store. Every movement has a defined source, destination, currency, and outcome, allowing merchants to understand what changed without reconciling across disconnected parts of the product.
This keeps behaviour consistent. As funds move, they remain visible within the same model used to describe balances, allowing merchants to understand changes without needing to reconcile across different parts of the product.
Transfers
Transfers move funds between sub-accounts within the Business Account, directly changing balances.
This is how merchants move funds between entities, currencies, and operational contexts. A transfer reduces the Available balance of one sub-account and increases another, changing the distribution of funds across the Business Account.
The risk sits at the point of commitment. Transfers often happen immediately, and mistakes are difficult to undo. Moving funds from the wrong sub-account, to the wrong destination, or in the wrong currency can have direct operational impact.
The design makes that change explicit before it happens. Source and destination are always visible together, scoped to a specific entity, sub-account, and currency. This ensures that the outcome of the transfer is clear before execution.
Above: End-to-end transfer experience, showing how merchants select a source and destination sub-account, review available balances, confirm same-currency or FX movement, and trace the completed transfer in activity.
Sub-accounts are filtered based on valid combinations. Unsupported routes are removed upfront, preventing invalid transfers rather than relying on error states later. This keeps the interaction constrained to what is actually possible within the system.
When transferring within the same currency, the behaviour is immediate. The entered amount is applied directly, and the resulting balance change is reflected without delay.
When transferring across currencies, the interaction introduces pricing and timing. A quoted FX rate is surfaced alongside the interbank rate and markup, making the cost of the transfer explicit.
Above: Cross-currency transfer details showing the selected accounts, source amount, converted value, FX rate and fees before review.
Rates are time-bound and update dynamically. The interface makes this visible, ensuring the user understands when the outcome may change. The entered amount remains the anchor, with the corresponding value adjusting as rates update.
All transfers pass through a confirmation step before execution.
Above: Confirmation step showing source, destination, amount, converted value and processing time.
This mirrors the final state of the transfer, showing exactly what will happen. Errors such as insufficient funds are surfaced inline against the sending sub-account, and expected timing is shown where processing is not immediate.
Once completed, transfers are recorded as movements between sub-accounts.
Above: Transfer activity showing movements between sub-accounts, grouped over time.
Each entry shows both the source and destination, making movements attributable and easy to follow. Transfers can be filtered and searched, allowing merchants to track how funds have moved across the Business Account.
Selecting a transfer reveals the full detail of what was executed.
Above: Transfer detail showing source, destination, amount, and if applicable, any fees, FX rate and converted value.
The detail view mirrors the confirmation step, creating a consistent relationship between what was confirmed and what was recorded.
This keeps transfers grounded in the Business Account model: funds move between known sub-accounts, in known currencies, with a clear origin and outcome.
Settlements
In this part of the Business Account, settlements represent payout events – funds leaving a sub-account for an external bank account.
This is the final step in the lifecycle of funds held on platform. Once paid out, those funds no longer sit within the Business Account balance.
The risk is loss of visibility. As soon as funds leave, it becomes harder to understand what has been paid out, what is still pending, and whether anything has failed or been delayed. Without a clear view, merchants are forced to reconcile against bank statements or external reports.
The design keeps settlements grounded in the same model as balances. Each settlement is a defined payout event, tied to a specific sub-account, currency, and destination account. This makes movement out of the system explicit and attributable.
Settlements are presented as a list of payout batches.
Above: Settlements list showing payout batches, including amount, status, destination account, and settlement date.
Each entry represents a single payout event. Status is surfaced directly, allowing merchants to distinguish between Pending, Complete, and Carried forward settlements. This makes it possible to understand what has been paid out, what is scheduled, and what cannot yet be paid.
Selecting a settlement reveals its full lifecycle.
Above: Settlement detail showing payout lifecycle, including creation, processing, and expected arrival in the receiving account.
The detail view presents settlements as a timeline. Events such as creation, approval, and payout are shown in sequence, making the movement of funds beyond the system visible over time.
A settlement is not a single transaction. It is a net payout made up of underlying activity such as payments, refunds, chargebacks, and adjustments. The interface exposes this composition, allowing merchants to understand how the total amount was formed.
Reports are attached directly to each settlement, providing downloadable breakdowns that match the payout exactly. This allows settlements to be reconciled back to the activity that generated them.
This keeps payouts connected to the account model, even as funds leave the platform. Funds move from a defined sub-account, in a specific currency, to a known external destination, every payout can be traced back to the activity that created it.
Corporate cards
Corporate cards are virtual payment cards issued from the Business Account, allowing funds to be spent directly from sub-accounts in the same way as a standard debit card, reducing Available balances at the point of authorisation.
Unlike transfers or settlements, where funds are moved deliberately between defined destinations, cards introduce continuous, distributed spend. Multiple users can consume funds simultaneously, across different merchants, currencies, and contexts.
The risk is loss of control. Spend happens in real time, often outside of finance workflows, making it difficult to understand where funds have gone, who has spent them, and how that relates back to the underlying account structure.
The design addresses this before any spend occurs. Cards are not generic instruments – they are explicitly configured against the underlying account model at the point of creation.
Above: Card creation flow showing selection of sub-account, assignment, and spend configuration.
Each card is tied to a specific sub-account and assigned to a user. A default maximum monthly spend limit is applied to every card by the system, which can then be reduced to reflect the intended use. This ensures that every card starts within a controlled boundary, while still allowing limits to be tailored as needed.
Cards are then presented as controlled spend instruments.
Above: Card overview showing individual cards, each representing a distinct spending context with tracked usage.
Limits define how much can be spent, while remaining limits update dynamically as transactions occur. This ensures that spend is constrained without requiring manual tracking.
Selecting a card reveals its activity and configuration.
Above: Card detail showing spend, limits, and recent transactions tied to a specific sub-account.
Transactions are recorded at authorisation, including pending and declined activity. Each transaction is tied to a merchant, category, and location, making spend immediately attributable. This removes the need to reconstruct spend after the fact. The context of each transaction is captured at the point of purchase, rather than reconstructed from external statements.
Individual transactions can be inspected in more detail.
Above: Transaction detail showing status, merchant information, and associated card and sub-account.
Transactions move from pending to finalised states, reflecting how amounts may change before settlement. This ensures that real-time spend remains visible while still accounting for final processing outcomes.
Cards also introduce direct controls into the interface. Cards can be frozen, limits adjusted, and ownership assigned without interrupting the underlying account structure.
These controls allow merchants to respond to spend as it happens, rather than relying on retrospective checks or external controls.
This makes spend part of the same financial system, rather than a separate card experience layered on top. Spend always originates from a defined sub-account, reduces an Available balance, and is recorded as attributable activity tied to a specific card, user, and transaction.
Borrow introduces a new capability within the Business Account – accessing funds earlier than the standard settlement lifecycle would allow.
In the default model, funds move through defined states – Pending → Available → Payable – before being settled out to a bank account based on a configured schedule. This keeps balances predictable, traceable, and aligned with reporting.
Borrow does not change the settlement model. It brings forward access to funds that would otherwise be paid out later.
The first product we added to Borrow was Accelerated Settlements, giving merchants earlier access to funds they were already due to receive, while creating a foundation for future credit-based capabilities.
The balance model is designed around clear state transitions and scheduled settlement behaviour. Early access is valuable, but it can make settlement timing feel ambiguous unless the product clearly separates what has already been paid out, what remains scheduled, and what has been brought forward.
The design keeps Borrow anchored to the same model as Store and Move. Early access to funds is surfaced directly within settlements, making it clear what has been accelerated and what remains on the standard schedule.
Accelerated Settlements allow merchants to receive funds from payments earlier than the standard settlement schedule.
Rather than changing how funds move, acceleration changes when eligible funds are paid out.
Acceleration is introduced directly within the settlement overview. Funds are separated into amounts already paid out, amounts scheduled for payout, and amounts available to be paid out instantly.
This prevents accelerated funds from being merged into a single total. It remains clear which funds have completed their lifecycle, which are still progressing through it, and which can be brought forward.
Above: Settlement overview separating paid out, upcoming and instantly available funds.
Acceleration operates at the level of sub-accounts and is bounded by defined limits.
The accelerated sub-accounts panel shows which sub-accounts are accelerating today, which are not, how much has already been accelerated, and how much of the daily limit has been used.
This made acceleration understandable without creating a separate Borrow interface. Merchants could see early access in the context of the settlement schedule they already used.
Above: Accelerated sub-accounts panel showing which sub-accounts are accelerating and how much of the daily limit has been used.
Each sub-account has a daily acceleration limit. Once that limit is reached, additional funds continue through the standard settlement flow. This maintains the integrity of the balance model while allowing flexibility in timing.
Acceleration also needed to remain tied to settlement configuration, not feel like a separate funding product layered on top.
The settings views showed acceleration inside the existing settlement schedule model. At the entity level, teams could see which schedules were accelerated across currencies, sub-accounts, payout frequencies and receiving bank accounts. At the schedule level, they could see the rules behind that acceleration, including the daily acceleration limit, payout threshold, payout frequency, time zone and bank account.
Above: Settlement settings showing accelerated schedules at entity level and the underlying schedule rules, including daily limit, payout threshold, frequency and receiving bank account.
This mattered because acceleration changed timing, not the underlying settlement model. Funds still originated from a sub-account, moved through defined balance states, and settled out through the same configured mechanism. The only difference was when eligible funds were paid out.
That made Accelerated Settlements a credible first step into Borrow. It gave merchants earlier access to liquidity without asking them to learn a new model, while proving that the Business Account could support future funding and credit-based capabilities without fragmenting the underlying system.
Once funds are clearly structured, and movement and timing are understood, the system can support additional ways of using those funds.
Grow extends the Business Account beyond holding and moving funds, allowing merchants to generate value from balances while they remain on platform.
This is not a separate system or product. It builds directly on the existing model – sub-accounts, balance states, and ledger movement – allowing new capabilities to be introduced without changing how funds are stored or how they behave.
The important point is that Grow depends on the work already done in Store, Move, and Borrow. Merchants need to trust where funds live, how they move, and when they can be accessed before those funds can become productive.
Yield was explored as a future capability, allowing merchants to earn a return on funds held within the Business Account.
Rather than introducing a separate product, yield would be applied directly to existing balances. Funds remain within the same sub-account structure, follow the same state transitions, and remain fully attributable to entity and currency.
The design challenge was ensuring that any return is clearly tied back to the underlying balance it is derived from. Earning on funds should feel like an extension of holding them, not a separate experience.
Above: Early concept showing yield applied to funds held within a sub-account, making earning on stored funds feel like an extension of the existing balance model rather than a separate product.
This principle extends beyond yield. Because funds are already partitioned by entity and currency, and move through defined states, new capabilities can attach to those structures rather than redefining them.
This allows the product to grow in capability without becoming harder to understand. Each new feature reinforces the same model, rather than introducing new rules or parallel systems.
For the Business Account, this was the strategic value of Grow. It showed that the platform could extend beyond visibility, movement, and early access into future financial capabilities without fragmenting the product or requiring merchants to learn a new model.
Rather than adding another financial tool to the Dashboard, Grow made the case for the Business Account as a scalable financial operating system – one where new capabilities could emerge through the same underlying account model over time.
Formal reconciliation still sits outside the Business Account, through the Dashboard's financial reporting. The product focuses on making everyday movement clear enough that merchants are not forced into reporting workflows for every question.
Monitor sits across Store, Move, Borrow, and Grow. It is not about performing actions, but about checking what has already happened.
In the Business Account, funds are structured across sub-accounts, move through defined balance states, and are settled based on configured schedules. Monitor makes those changes traceable, allowing merchants to understand how funds moved through the system and where to investigate when something does not look right.
Above: The Dashboard overview showing consolidated available balance and entity-level balance summaries, giving merchants a high-level way to monitor their funds position before moving into detail.
The first level of monitoring was awareness. Merchants needed a quick read on the overall funds position, with enough context to see which entities contributed to the total and a clear route into the deeper balance experience.
The overview deliberately stayed lightweight. It was not trying to become a treasury workspace. It gave merchants a visible signal of account health at the point they entered the Dashboard, then let them move into Balances and activity when they needed more detail.
This is what makes the rest of the system credible. Merchants can hold, move, access and spend funds with more confidence when they can see the position clearly and trace the activity behind every balance change.
Balance activity makes the underlying ledger inspectable inside the product.
Rather than showing a balance as a static number, it shows how that balance changed over time and which events contributed to the movement.
Every change, whether from payments, settlements, transfers, top-ups, fees or card spend, updates a balance. The design needed to make those changes understandable without forcing merchants into exported reports for basic tracking.
The interface supports both quick inspection and deeper investigation. At a glance, merchants can see how balances have changed. When needed, they can trace those changes back to specific actions within the account.
The chart gives a high-level view of funds moving in and out across the selected period, while the table exposes the breakdown beneath it, including opening balance, funds in, funds out, net change and closing balance.
Above: Balance activity showing how funds moved in and out over time, making changes traceable to individual events without leaving the Business Account.
Instead of only showing that Available balance changed, this view explains what activity contributed to that change. The table can expose the breakdown beneath the movement, including categories such as captures, top-ups and transfers.
At the sub-account level, the interface shifts from aggregation to individual activity.
Instead of summarising balances across the entity, this view shows events as they occur within a single sub-account and currency. Each entry is timestamped and tied to a specific activity, making it possible to trace how balance changes were formed.
Above: Sub-account view showing chronological account activity for a single currency, including settlements, withdrawals and transfers.
Together, these views provide both overview and traceability. Balances can be understood at a high level across entities, or inspected at a granular level within a single sub-account, without breaking the underlying model.
Settlements and transfers have already been covered as actions within Move. In Monitor, their role is different. They provide a record of what happened after execution.
Rather than redefining how settlements and transfers work, the product exposes their outcomes as connected events. This allows merchants to follow movement after the fact – where funds came from, where they went, what status they reached, and how they affected the account.
This helps answer practical questions without immediately falling back to reports. Why did this balance change, was this payout completed, which transfer moved these funds, and what activity contributed to this settlement?
Above: Transfer activity showing how completed movements can be followed after they occur, including timing, source, and destination.
The goal was not to recreate formal reconciliation inside the Business Account. It was to make everyday financial movement understandable enough that merchants could investigate, explain, and trust what they were seeing before moving into formal reporting workflows.
Monitor completes the system by making it verifiable. Funds are not only visible, movable, accessible earlier, and productive – they can also be traced back through the activity that changed them.
The challenges in the Business Account weren't isolated feature problems, but system level tensions between clarity and completeness, flexibility and control, and speed and coherence.
The Business Account's defining design challenge was coherence.
Each capability – Balances, Transfers, Settlements, Corporate Cards, Funds Pooling, and Accelerated Settlements – had its own engineering team, constraints, and interaction logic. Left alone, they would have formed a set of disconnected financial tools.
The challenge was to establish a shared language – structural, visual, and terminological – that made them feel like parts of a single Business Account, rather than a collection of features with a shared header.
This was not just about interface consistency. It meant defining common rules for how funds were structured, how movement was represented, how balance states behaved, and how activity could be traced across the system.
The Business Account served treasury and finance professionals who needed granular detail – multiple balance states, settlement progression, FX markups, payout timing – and general managers who needed a simple answer to "what do I have available?"
Designing a single interface that served both without compromise required precise decisions about hierarchy and disclosure.
The surface of the product needed to provide clarity quickly, while deeper views needed to expose the operational detail required to investigate, reconcile, and act with confidence.
The challenge was knowing where detail added trust, and where it created noise.
The Business Account put the Design team in close contact with enterprise treasury management – a specialist domain where users often knew more than the people designing the product.
We risked oversimplifying and building something finance experts would dismiss as not for them, or defer too readily to complexity and reproduce treasury software patterns without questioning whether they were necessary.
We kept tight feedback loops with treasury and finance experts throughout, and developed enough domain literacy to know when to simplify and when complexity was load-bearing.
That became especially important when working through concepts like balance states, settlement timing, FX costs, payout schedules, and reconciliation. These were not just details in the interface. They shaped whether merchants trusted the system.
The Business Account was delivered across phases, not as a single launch.
Each phase needed to feel complete to the merchants using it, even though the product itself was still expanding. New capabilities had to integrate into the same account model without introducing fragmentation or forcing merchants to relearn how the system worked.
The five verb framework helped here. Store, Move, Borrow, Grow, and Monitor gave each release a clear position within the overall arc, so new functionality could be introduced without breaking the underlying system.
This made sequencing a design problem as much as a product problem. Store needed to establish trust before Move could ask merchants to act. Move needed to make settlements legible before Borrow could introduce acceleration. Grow only made sense once merchants were confident leaving funds on platform.
The challenge was shipping incrementally without making the product feel unfinished, and scaling capability without turning the Business Account into another set of disconnected tools.
Between Q1 2025 and Q1 2026, the Business Account proved the central product bet. When merchants could understand where funds were held, when they could use them, and how money moved through the system, they were willing to keep and operate more funds on platform.
The impact showed up across merchant behaviour, liquidity, operational efficiency and usability. Funds held and used on platform grew significantly, Accelerated Settlements created a new liquidity behaviour, and standardised settlement models reduced the need for bespoke operational work.
Funds held on platform
$731M
+101% YoY
Total value of funds held across all Business Accounts (Q1 2026)
This was the core behaviour change the product set out to create. Merchants who had previously swept most funds out of Checkout were now treating the platform as a place money could live.
Balance utilisation
$853M
+113% YoY
Funds used across payouts, cards and transfers (Q1 2026)
Held funds only matter if they become operational. Utilisation growing faster than holdings showed that merchants were not just parking money on platform. They were running parts of their financial workflow from it.
Monthly acceleration
$595M
Monthly volume of funds accessed early via Accelerated Settlements (Jan 2026)
Adoption at this scale depended on the settlement-legibility work. In testing, merchants would not accelerate funds confidently if they could not understand what was being brought forward, what remained scheduled and how the standard settlement flow worked.
Standard settlements
94.2%
Adoption of the default settlement model (Jan 2026)
This showed that more merchants were accepting the productised settlement model rather than relying on bespoke configurations. That was important because the goal was not only to expose settlement data, but to make complex settlement behaviour understandable enough to scale.
Manual operations reduced
37%
Reduction in manual settlement workflows (2025)
This connected directly to the problems found in research. Finance teams had been manually checking balances, calculating settlement amounts and reconciling across disconnected sources. Forecastable pending funds and traceable balance activity gave them a clearer way to understand what was happening inside the account.
Liquidity risk mitigated
$100M
Reduction in unmanaged liquidity exposure per year (annualised)
This showed the value of making funds easier to understand, allocate and act on before they became a downstream operational problem.
System usability
89/100
System Usability Scale
Usability of onboarding and the account experience.
The significance of these outcomes is that they were not isolated feature metrics. They showed that merchants were willing to hold funds, use funds, bring funds forward and accept standardised financial workflows when the account model was clear enough to trust.
These were business outcomes with many contributors across Commercial, Product and Engineering. The design contribution was the model that made the behaviour possible. Merchants do not hold nine figures on a platform whose balances they cannot trust, and they do not adopt default settlement models they cannot read.
