Refund Right

Refund the extra payment. Keep the access they paid for.

Comment

Inspiration

Imagine buying a digital pass. Checkout stalls, so you try again. Now you have two receipts. You ask support to refund the extra purchase—but you still need the access you paid for.

That is the problem behind Refund Right: resolving a payment mistake while preserving the customer’s valid access.

The broader problem is measurable. In Chargebacks911’s 2025 survey of US and UK cardholders with recent dispute experience, approximately 22% cited overcharges or multiple charges as a reason for contacting their bank to dispute a transaction. That figure describes the surveyed group, not all shoppers. Source: 2025 Cardholder Dispute Index

We focused on a specific support task where customer intent, payment records, and access permissions must agree.

What it does

Refund Right gives support operators a workspace for reviewing duplicate purchases and approving a precise resolution.

It connects the customer’s request to individual PayPal captures and the access grants each purchase funded. Gemini proposes a resolution with supporting evidence. The application then checks the proposal and shows exactly:

  • Which payment will be refunded.
  • Which linked access grant will be removed.
  • Which independently paid access will remain.

A human approves that specific action. Refund Right then verifies the PayPal refund and checks the retained access separately.

When the request is ambiguous, the workflow asks for clarification. When a payment outcome is unknown, it preserves the original operation for reconciliation.

The dashboard brings ongoing cases, refund amounts, and resolution states into one view.

How we built it

We built the interface with React and TypeScript, backed by Express and SQLite.

Gemini’s Interactions API interprets customer requests alongside case evidence and returns a structured proposal. Server-side validation checks the proposed capture, amount, currency, ownership, and access relationships before creating an immutable preview.

PayPal’s Orders and Payments REST APIs provide the actual sandbox checkout, capture, refund, and verification flow.

Using the Model Context Protocol SDK, we implemented four tools:

  • prepare_refund_case
  • get_refund_preview
  • submit_for_approval
  • get_resolution_status

These let an AI agent prepare work for review. Approval and refund execution remain controlled by the application and human operator.

Approvals are tied to the case version and exact preview. Persistent operation records and capture reservations protect against repeated or concurrent execution.

Challenges we ran into

The hardest challenge was connecting a refund to the correct access change. Two payments can have the same amount while funding different grants, so matching on price alone is insufficient.

We also had to handle uncertainty across systems. A timeout does not prove that a refund failed. We built explicit pending, unknown, and partially resolved states, with a reconciliation path instead of blindly submitting another refund.

AI evaluation exposed unsupported refund-policy wording in an early response. We tightened the instructions and retested the affected case, reinforcing the importance of validating model output.

Accomplishments that we're proud of

We completed a real end-to-end PayPal sandbox test using simulated funds:

  • Two human-approved $29 purchases were captured.
  • Gemini identified the extra purchase.
  • A human approved the exact refund.
  • PayPal readback confirmed the $29 refund completed.
  • Only the extra access grant was revoked.
  • The original paid Library still opened successfully.

The project also includes 39 passing automated tests, real MCP protocol tests, and successful typecheck and production builds.

Our most meaningful result is simple: two payments, one precise refund, one valid pass.

What we learned

Successful resolution requires verifying both the money and the customer’s access.

We learned to give AI a bounded role: interpret intent and propose a resolution, while deterministic checks and human approval govern execution.

We also learned to distinguish evidence carefully. A successful sandbox case demonstrates a working integration. Broader reliability, accuracy, and support-time improvements require more evaluation.

What's next for Refund Right

Next, we want to test with support operators using unfamiliar cases and measure decision quality and handling time against a manual workflow.

We also plan to expand evaluation of ambiguous requests, interrupted operations, and access failures; improve reconciliation tooling; and explore integrations with real digital-product access systems.

The current prototype focuses on full refunds for sandbox USD captures. Partial refunds, subscription adjustments, and broader merchant support are future work.

Our goal remains the same: refund the extra payment and keep the access the customer paid for.

Built With

Share this project:

Updates

Submission history