Inspiration

We kept noticing the same small drama after online purchases. You buy something, and three days later it is cheaper. So you either return it and rebuy, or you stew about it and leave a bad review. Either way, the shop loses.

Returns are the expensive route for merchants. Shipping, restocking and open-box discounts add up. With the default numbers in our app, taking back a $398 pair of Sony WH-1000XM5 headphones costs about $171.61. Refunding the $78.01 price difference costs $78.01. The merchant keeps the sale, the buyer keeps the headphones, and about $93.60 of margin is protected.

Most PayPal projects focus on checkout. We wanted to build for the weeks after it, where a lot of money quietly leaks out.

What it does

DropBack is 14 day price protection for merchants who take payment through PayPal.

  • Buy: A buyer pays through PayPal. Prices are set on the server, and the order is captured after approval.
  • Check: Within 14 days, the buyer opens their order page and checks the live market price. Channel3 returns current in-stock offers for the exact product. If there is a lower one, the buyer sends a price match request.
  • Review: The merchant sees the request in an AG Grid case queue. Each case shows the Channel3 offer, the chance the buyer would otherwise return the item, the cost of a return next to the cost of settling, and a drafted reply.
  • Refund: On approval, DropBack sends a partial PayPal refund of the verified difference to the original capture. The buyer's page updates with the refund and the merchant's message.

No refund is ever automatic. Every payout needs a person to click approve, and the API rejects any attempt to turn auto refunds on.

How we built it

  • Backend: FastAPI, SQLAlchemy 2, Alembic, SQLite locally and PostgreSQL in Docker.
  • Frontend: React 19, TypeScript and Vite.
  • PayPal: Orders v2 for create and capture, JS SDK v6 for the checkout modal, Payments v2 for partial refunds. Every money call carries a PayPal-Request-Id, and webhooks are signature verified and de-duplicated by event id.
  • AI: OpenAI gpt-4.1-mini (Gemini 2.0 Flash as an alternative) returns a return probability, risk drivers, a short rationale and a drafted buyer message.
  • Channel3: exact product search, a match scorer, subscriptions for price changes, and a signed webhook that re-fetches the product before recording anything.
  • AG Grid: the case queue, decision history and orders tables.
  • APIMatic: a PayPal context manifest for Orders v2 and Payments v2, used by our API Lab page.

The model never has the last word. Plain rules decide whether a refund is allowed at all (inside the window, above the minimum drop, within the per order cap and daily budget). The model's probability is blended 50/50 with a rule based baseline, and if the model is down, we fall back to rules and say so on the report.

Challenges we ran into

  • Sandbox currency. The PayPal sandbox seller rejected USD at buyer approval, which blocked capture and refund testing until we fixed the seller account setup.
  • Matching the right product. A search for "WH-1000XM5" can return the XM4 or a bundle. We wrote a scorer that rejects conflicting model numbers and variant words, because a wrong match means refunding for a price that does not apply.
  • Honest savings. Our first version treated avoided returns as guaranteed. Expected savings are now return probability times return cost, minus the refund.
  • Not paying twice. Refunds can fail halfway, retry or race. Each decision gets one refund row with a fixed idempotency key, and the per order cap and daily budget count pending refunds too.
  • Channel3 is not instant. Subscriptions refresh daily, so we added a live check button for the demo and treat webhooks as the ongoing source.

Accomplishments that we're proud of

  • A full sandbox run from buyer checkout to a completed refund: a $398.00 capture, a live Channel3 offer of $319.99, and a $78.01 PayPal refund the buyer can see.
  • Human approval on every refund, enforced in code and not only promised in the README.
  • Careful product matching and money handling that we would be comfortable showing a real merchant.
  • Finished screens for both the buyer and the merchant, so it feels like a product and not just an API demo.

What we learned

  • PayPal refunds depend heavily on idempotency, and totals are easy to get wrong without it.
  • Language models are great at explaining a decision and drafting a friendly message, but rules should own the numbers.
  • Open web price data is messy. Match quality matters more than how many offers come back.
  • An honest demo takes effort. We label the 14 day window as an accelerated Day 3 scenario instead of pretending time passed.

What's next for DropBack

  • Multi-merchant support with PayPal partner onboarding.
  • Registered public webhooks so price drops arrive without anyone pressing a button.
  • A price exposure chart showing how much refundable value sits inside the protection window.
  • Real return history to replace our starting guesses in the return probability model.

For trying out

Use the following credentials [email protected] dropback-demo

Built With

Share this project:

Updates

Submission history