What started as a push to speed up payment became a harder product problem
Sellers and B-Stock wanted payment to happen sooner so orders could move faster. But buyers had long been used to deciding when to pay, often through manual methods like wire.
I first explored whether mandatory auto-charge could work. Later, when the mandatory path was being stretched to accommodate too many exceptions, I proposed an alternative and tested both directions. That helped reopen the discussion across teams and move the work forward.
In the traditional liquidation industry, inventory often moved through a longer chain before reaching business buyers. On B-Stock, that path became more direct: enterprise sellers listed inventory, and business buyers bid through auctions.
This case focuses on what happens after a buyer wins, but before payment is completed.
After a buyer won, payment did not happen right away. Buyers still had to come back and pay, and many used wire instead of paying online.
So the slow part was step 2: payment. B-Stock could not tell the seller to ship until payment was completed, so inventory often sat in warehouses longer than it should.
The first goal was simple: make step 2 faster.
Seller and B-Stock were more aligned, so the team moved forward with an auto-charge direction. My next step was to design it and test whether buyers would accept it.
The first direction was to auto-charge buyers after they won an order.
To support that, the product had to change in two places. Buyers needed to see the expectation earlier, and payment setup had to move earlier in the flow.
I turned that first direction into a prototype and tested it with buyers. Early feedback was encouraging: 25 of 29 said it felt acceptable.
The main concern was not the idea itself, but wanting a short grace period after winning. I brought that learning back to the team, we agreed to include a grace period, and I worked with engineering to deliver the auto-charge MVP.
From the start, we knew some large buyers used wire only. In the first MVP, that was an intentional scope choice: we had planned to start with a narrower pilot seller and accepted that those buyers would stay out of scope.
A couple of months later, that tradeoff was no longer acceptable. Stakeholder alignment broke down around one question: this direction now had to include large wire-only buyers too.
The next ask was exceptions — for example, whitelists or thresholds. But to me, that was the moment the original direction started to break down.
Instead of staying with one path and adding exceptions, I turned the new question into a second direction. Then I prototyped both and tested them with buyers.
Auto-charge applies to everyone.
Some buyers then need exceptions.
That made Direction 1 riskier, so it needed a pilot seller first.
Buyers can choose auto-charge or keep the old flow.
If they do not opt in, they keep paying the way they always had.
That lowered the risk, so Direction 2 could work across the whole platform.
What the testing showed
Preferred direction
Direction 2 was clearly preferred
Expected opt-in
Even with buyer choice, expected opt-in stayed high at 93.75%
Risk in Direction 1
Exceptions reduced bidding engagement and could weaken auction performance
Business implication
Direction 2 was safer to roll out across the platform
The testing did not lead directly to my exact optional UI, but it helped the team step back from exception-based solutions and rethink the problem.
What shipped kept the same core idea: giving buyers a choice. Buyers who chose online payment were auto-charged, while buyers who chose offline payment (wire) stayed manual.
That shift mattered. By the time I tested the two directions, about four months had passed since the work began. It helped the team move past the idea that auto-charge had to stay mandatory, with wire-only buyers handled through exceptions. It also opened a path beyond a one-seller pilot toward a broader rollout.