A Cart That Could Not Handle Its Own Promotions
A consignment marketplace had grown past what its original cart could handle. The platform's bespoke checkout was built on custom logic that worked until it didn't. Promotions were a lacuna in the design. The code couldn't apply a discount to one item without applying it to the whole order. The practical workaround was to restrict the cart to a single item whenever promotions were active. That held for a while, but it was capping revenue and making consignor payouts unreliable.
The payout problem was downstream of the cart problem. Salesforce was the system of record for all orders, products, and customer data. The consignor payout jobs ran periodically inside Salesforce and pulled from order-level summaries. When a mixed order came through with a discount applied to the whole basket, the math was wrong. Two items from two different consignors could end up sharing a discount that only one of them had agreed to.
The correct fix wasn't a patch on the Salesforce side. It was getting the right data in there to begin with. Sequoia Applied Technologies was brought in to audit the codebase, scope the work, and deliver the rebuild.
Audit First, Then Build
Sequoia Applied Technologies is a Santa Clara software engineering firm. We build and rebuild software products for technology companies across eCommerce, life sciences, enterprise software, and IoT. This engagement started with a full codebase audit before any development work began.
The audit covered the existing React and Node codebase, the Salesforce integration, and all third-party connections including Stripe, Debounce, Numverify, and the analytics layer. Findings were bucketed into three categories: must-fix, should-fix, and nice-to-fix. The client reviewed and signed off on the requirement specification before implementation started.
Implementation ran on two-week sprints with show-and-tell sessions at each cycle. The Salesforce work was handled by a certified Salesforce developer working alongside the React and Node team. Separate staging and production environments were in place from day one so no testing ever touched live order data or payment systems.
Beyond the cart rebuild there were several other pieces that had accumulated: no fraud validation at order placement, gift card edge cases around duplicate redemption, thin analytics coverage, and an inventory lock for high-demand drops that needed revisiting. All of it went through the same audit-and-scope process before any code was written.
Six Areas of the Platform Rebuilt or Fixed
The work split across the cart and checkout layer, the Salesforce integration, the fraud validation layer, payments, analytics, and inventory control. Each had its own scope and its own review cycle before it went to staging.
Rewrote the cart to support item-level discount logic using React and Node. A single order can now hold promotional and full-price items. Discounts apply per line item so order totals are correct and the data flowing to Salesforce is clean. The one-item constraint during promotions is retired.
Rebuilt the data flow so each order carries item-level discount information into Salesforce, not just order summaries. The provenance of every discount is preserved through the transaction. Payout calculations now reflect actual per-item math rather than approximations from basket-level totals.
Added server-side validation hooks that run before an order is placed. Email is checked via Debounce, phone via Numverify, and shipping address against verification rules. Suspicious signals are flagged without adding friction for genuine buyers. The checkout experience is unchanged for real customers.
Stripe-based gift cards with balance tracking and redemption rules. Duplicate redemption attempts and insufficient balance are caught before an order completes, not after. Edge cases that had been causing order failures were identified during the audit and addressed in the rebuild.
Enhanced eCommerce event tracking across the full purchase funnel via Google Tag Manager. GA4 funnel data is clean and readable. Product teams can run A/B tests through Google Optimize and interpret results without digging through raw event logs to find gaps in coverage.
DynamoDB-based lock with timed expiration prevents double-selling on single-item listings. The lock is acquired at cart entry, not at checkout, so high-traffic drops stay fair under concurrent load. A limited item cannot be sold twice even when multiple buyers reach the payment step simultaneously.
The Stack the Rebuilt Platform Runs On
The platform is a React frontend backed by a Node API layer, running on AWS serverless infrastructure. Lambda handles compute, API Gateway manages routing, and DynamoDB handles the inventory lock and session state. Elasticsearch powers catalog search. Salesforce remains the system of record for orders, customers, and consignor data.
Stripe handles payment processing including standard checkout and the gift card system. Debounce and Numverify provide the fraud validation signals at order placement. Google Analytics and Google Optimize handle tracking and experimentation, instrumented through Google Tag Manager so the product team can adjust events without touching the codebase.
The serverless architecture means the platform scales to traffic spikes without pre-provisioning. High-demand item drops that previously created race conditions are handled cleanly by the DynamoDB lock layer. Staging and production are separate environments with separate Salesforce sandboxes, so QA cycles never touch real consignor data or payment flows.
Common Questions About eCommerce Software Development
What kind of eCommerce software development does SequoiaAT do?
Sequoia Applied Technologies builds and rebuilds custom eCommerce software for product companies. Work includes cart and checkout development, payment integrations, Salesforce and third-party API integrations, fraud validation, and analytics instrumentation. We work primarily on React and Node stacks with AWS infrastructure.
What did SequoiaAT change in the cart and checkout?
We rewrote the cart to support item-level discount logic. Previously the platform could not mix promotional and full-price items in the same order. We rebuilt checkout so discounts apply at the individual item level, keeping order totals and downstream Salesforce data accurate. The single-item workaround that had been restricting multi-item promo orders is gone.
How did SequoiaAT fix the consignor payout calculation?
The original Salesforce jobs calculated payouts from order-level summaries, not item-level data. When a mixed order flowed through, a discount on one item could reduce the payout for a different consignor. We rebuilt the data flow so item-level discount information travels from the web application into Salesforce with each order, giving consignors accurate payouts.
How did you reduce fraud without hurting conversion?
We added server-side validation hooks that run before an order is placed. These check email via Debounce, phone via Numverify, and shipping address against verification rules. Suspicious signals are flagged without adding checkout friction for genuine buyers. The validation runs entirely server-side and is invisible to customers who pass it.
What does a software development engagement with SequoiaAT look like?
We run a two-phase approach. The first phase is a discovery and codebase audit, which produces a signed requirement specification before development begins. Implementation follows a hybrid agile process with two-week sprints, show-and-tell sessions at each cycle, and a QA cycle before UAT handover. Scope changes are reviewed and signed off before becoming part of the deliverable.