Health-Benefits Commerce Platform
Members hold pre-loaded health-benefit funds, but that money sits with a third-party administrator rather than the store — so it could not be spent reliably online. Marsos built the payment and identity layer that lets members spend those balances directly at checkout, arrive already signed in from their benefits provider, and see every expense and reimbursement in one dashboard.
Delivery signals
Hybrid routing — running two storefronts as one site
63.28%
of all revenue through cardless benefits payments
48.12%
of site sessions arriving via partner SSO entry
+121.1%
YoY partner-program revenue growth
8+
payment methods composable on a single order
Percentage metrics verified from platform analytics, first ~30 days after the cardless program launch.
01 / Context
The operating environment
A US health-benefits commerce platform lets customers purchase eligible products and manage benefits-related activity. The engineering work covered four connected modules: an HSA expense dashboard, partner SSO, cardless benefits-balance payments, and split or multi-payment orchestration.
02 / Business outcome
What changed for the client
The result this engagement delivered — before any of the engineering behind it.
63.28% of all revenue flowed through the cardless payment method during approximately the first 30 days after launch.
Partner-program revenue grew 121.1% year over year, while overall programme revenue grew approximately 45% year over year across the comparison period.
48.12% of all site sessions arrived through the cardless TPA entry point during approximately the first 30 days after launch.
Overall programme sessions grew 58.6% year over year.
The shared SSO framework supported more than six partners through configuration and small partner-specific hooks rather than core rewrites.
03 / Challenge
Business need vs. technical reality
Each requirement collided with a hard platform constraint — this is the gap the engineering had to close.
Business need
Technical constraint
Business need
Members must spend pre-loaded benefits balances directly at checkout — cardless or carded.
Technical constraint
The balance is held by the partner and reachable only through a middleware API; the storefront must treat it as a native payment method.
Business need
The balance shown while shopping must be trustworthy at the moment of charge.
Technical constraint
Balances change externally through other channels and plan expirations — display-time balance is not charge-time balance.
Business need
A single order may combine store credit, rewards, benefits balance, benefits card, an FSA administrator payment and a credit card.
Technical constraint
The platform's reference architecture assumes one payment instrument; multi-instrument orders need explicit allocation, ordering and failure semantics.
Business need
New benefits partners must be onboardable quickly, without a code rewrite each time.
Technical constraint
Partners use heterogeneous SSO protocols — OAuth/OIDC and SAML — each with quirks in payloads, attribute mapping and redirect rules.
04 / Delivery
What Marsos engineered
Built a self-service expense and reimbursement dashboard using live Order Management reads plus scheduled lifecycle synchronization.
Created a configuration-driven partner SSO pipeline supporting OAuth or OIDC and SAML with partner-specific hooks.
Modeled cardless benefits balances as a first-class payment method with charge-time validation and compensating refunds.
Implemented declarative split-payment sequencing that supports more than eight payment methods on one order.
05 / How it works
How a cardless order settles
The system, one step at a time — the sequence that carries an order, a shipment or a decision from start to done.
- 01
Partner SSO login
The member arrives from their benefits partner and lands authenticated, partner-branded, with campaign attribution intact across the handshake.
- 02
Balance fetch
Pre-loaded benefits funds are pulled from the partner and stored on the profile — amounts, accounts and expiry dates.
- 03
Shop with live funds
A balance tracker shows available funds per account and plan type; the nearest expiry drives expiration messaging.
- 04
Re-validate at checkout
The balance is re-fetched inside the payment step — never trusted from the session — and capped at min(balance, order total).
- 05
Charge and arbitrate
The partner charge is arbitrated three ways: paid in full succeeds; paid zero declines; paid partially triggers an automatic compensating refund, then declines cleanly.
- 06
Refresh and recover
After every charge or refund the balance is refreshed from the partner, and the checkout recomputes which payment options remain valid so the shopper is never dead-ended.
06 / System Architecture
Architecture revealed as a system story.
Scroll through the technical decisions to see how each platform layer connects to the next.
01 · Health-benefits commerce platform
Open full-size diagram ↗The commerce estate end to end: storefront environments, the order management system of record, and the surrounding services for tax, fraud, loyalty, identity, affiliate tracking and fulfilment. Solid lines are real-time calls; batch transfers are shown separately, which is what makes the reimbursement timing behave the way it does.
02 · Hybrid routing — two storefronts, one domain
Open full-size diagram ↗How a composable storefront and the incumbent platform serve the same domain simultaneously. Traffic is split at the CDN per route, so pages migrate one at a time and any route can be sent back to the original platform without a redeploy.
Active decision
Used real-time API reads where freshness mattered and scheduled jobs for lower-cost order-lifecycle synchronization.
Architecture decision
Used real-time API reads where freshness mattered and scheduled jobs for lower-cost order-lifecycle synchronization.
Architecture decision
Normalized different partner identity protocols behind one account-resolution and attribution pipeline.
Architecture decision
Protected payment integrity with balance refresh, partial-capture refund, full reversal, and concurrency-safe token handling.
Architecture decision
Validated split totals before any charge and failed fast with compensating reversals when a payment leg failed.
07 / Engineering highlights
Where the hard problems were won
The proof points a technical buyer should inspect first.
Impact
Zero stranded captures by design
Three-way arbitration of the partner's paid amount — full, zero, or partial — with an automatic compensating refund on partial payment. Money never gets stuck between systems.
Impact
Charge-time truth
The benefits balance is re-validated inside the payment authorization itself, then refreshed after every charge or refund — display state and money state can never silently diverge.
Impact
One framework, two protocols
6+ benefits partners onboarded through configuration plus small hook modules — OAuth/OIDC and SAML share one pipeline, hook surface and account-resolution logic. No core rewrites per partner.
Impact
Split-total integrity before money moves
Multi-payment allocation is transactional and validated to the cent against the order total; a mismatch aborts checkout before the first charge is attempted.
Impact
Deterministic failure semantics
Fail-fast on the first failed payment leg, atomic order failure, and compensating reversals across every already-charged method — each with its own gateway semantics.
Impact
Compliance-aware audit logging
Every read, upload, update and delete touching customer expense data (potential PHI/PII) is explicitly logged, with hybrid real-time and batch sync keeping per-request cost low.
08 / Technology
The delivery stack
Salesforce Commerce Cloud
SFRA
Salesforce Order Management
Middleware APIs
OAuth / OIDC
SAML 2.0
Payment Orchestration
Scheduled Jobs
Confidentiality protocol
Use only approved public storefront imagery and generic system names. Do not publish internal modules, partner identities, absolute revenue values, credentials, or raw source documents.
Build with Marsos
Bring us the difficult system.We will make it buildable.
Start with a clear technical direction, an architecture that can scale, and a delivery plan your team can trust.