Pinky Promise

Plain-English guarantees that refund themselves through PayPal. A seller writes the promise, AI turns it into a rule, and when the promise breaks, the money goes back with the evidence attached.

Comment

Inspiration

Every small business makes promises: "money back if it rains", "free if we're late", "full refund if the session is cancelled". Buyers rarely believe them. Claiming means an email thread, a wait and an argument, so the guarantee reads as marketing, not protection. The buyer either doesn't book or books with a bigger brand.

The seller has the opposite problem. Honouring a guarantee by hand means checking what happened, deciding, finding the order and issuing the refund. Most simply don't offer one.

Parametric insurance already solves this for crops and flights: the payout is tied to a measurable event, not a claim. But it's sold by insurers to big customers. Nobody offers it as a checkout feature that a tour guide, tutor or food truck can switch on in one sentence. We wanted to build that: a promise that keeps itself.

[Optional: add one personal sentence here, e.g. a time a guarantee wasn't honoured for you.]

What it does

Pinky Promise attaches a self-executing guarantee to a PayPal checkout.

  1. The seller writes the promise in plain English. For example: "If more than 5 mm of rain falls during the tour, you get 50% back."
  2. AI compiles it into a rule both sides can read: the metric (rainfall), the threshold (> 5 mm), the time window and location, and the refund ($10 of $20). It also lists the assumptions being agreed to, such as the data source. Vague promises like "if the weather is bad, you get your money back" are rejected, with a measurable rewrite suggested. The seller confirms before anything goes live.
  3. The buyer sees the exact rule before paying, right beside the PayPal buttons, and checks out with PayPal (sandbox) or with a clearly labelled demo checkout.
  4. A durable workflow watches the promise. It sleeps until the window closes, fetches the weather evidence, and compares it with the rule in plain code. If the promise is broken, it issues the refund through PayPal with an idempotency key, and the receipt shows the whole story: booking, evidence, rule check, refund and a plain-English explanation.

Nobody files a claim. Nobody argues. The rule is checked by code anyone can verify.

The trust split: AI writes the rule and explains the decision. It never decides a number or a refund amount. Deterministic code compares the evidence with the threshold and does the cents math. PayPal moves the money.

Supported today: total rainfall, max/min temperature and max/min wind; percentage or fixed-dollar refunds; five city presets; whole-hour UTC windows of 1–24 hours within the next 14 days.

How we built it

  • Frontend: React + Vite, with a seller workspace, public checkout and live receipt. It is responsive down to 390 px and handles reduced motion, focus traps and loading, empty and error states.
  • API: a Cloudflare Worker running Hono, with Zod validation on every input and every AI output.
  • AI rule compiler: Workers AI, @cf/meta/llama-3.3-70b-instruct-fp8-fast, in JSON Schema mode with server-side Zod validation and one retry. It returns a rule, a rejection with a reason and a suggested rewrite, or a clarification request. A confirmed rule preview is stored server-side, so a client cannot swap in a different rule at publication. Paid rules are immutable.
  • PayPal: the JS SDK for buyer approval; Orders v2 for server-side order creation and capture (with capture recovery after a lost response); Payments v2 for refunds with a stable idempotency key; and verified webhooks for PAYMENT.CAPTURE.COMPLETED and PAYMENT.CAPTURE.REFUNDED, deduplicated by event ID.
  • Settlement: one Cloudflare Workflow per promise. It sleeps until the measurement window closes, claims settlement atomically, fetches evidence with retries, compares it in code, refunds, records the explanation, and finalizes the receipt. A five-minute cron restarts any promise still "watching" past its window.
  • Evidence: Open-Meteo hourly weather, with the source URL and samples stored on the receipt. Missing, null or partial data sends the promise to review; it is never treated as zero.
  • Storage: D1 for immutable offers, promises and the event timeline; KV for compile previews, tokens and the weather cache.
  • Demo path: a "Simulate conditions" control injects evidence (e.g. 12 mm of rain) through the same workflow. Simulated evidence and demo payments are labelled everywhere.

Challenges we ran into

  • Keeping AI away from the money. It's tempting to let the model judge "was the promise broken?". We confined it to compiling and explaining, and made the decision a deterministic comparison with cent-based caps, so the outcome is auditable and repeatable.
  • Exactly-once refunds. Retries, duplicate webhooks and a user clicking twice can all cause a double refund. We added atomic settlement ownership, a stable refund idempotency key, webhook deduplication by event ID, and a 409 on any duplicate settlement attempt. There is deliberately no blind "retry refund" button.
  • Honest evidence. Weather APIs return gaps. We treat incomplete data as "needs review" instead of "0 mm, no refund", and we use the preceding-hour convention for precipitation intervals so the window boundaries are unambiguous.
  • Vague promises. "If the weather is bad" can't be measured. The compiler has to refuse it and suggest a measurable version, rather than guess.
  • Sandbox realities. PayPal refuses self-payments, so the buyer must be a separate personal sandbox account. We also built a labelled demo checkout so judges can run the whole loop in under two minutes without one.

Accomplishments that we're proud of

  • The full loop works live: write a promise → AI rule → checkout → simulated rain → durable workflow → $10 refund on a $20 booking, with the reason written on the receipt.
  • A real settlement from actual Open-Meteo weather data (0 mm, promise kept).
  • Subjective and multi-condition guarantees are rejected with an explanation and a rewrite.
  • Duplicate settlement returns HTTP 409; unauthorized seller API calls return 401; unsigned webhooks return 400.
  • No browser JavaScript errors in the full demo flow, and no horizontal overflow at 390 px.
  • Built solo, end to end, within the hackathon window.

What we learned

  • The most trustworthy use of AI in payments is translation, not judgement: turn human language into a precise, inspectable rule, then let ordinary code and PayPal do the rest.
  • Durable workflows fit promises naturally. A promise is a long-running, sleeping process with exactly one ending.
  • Idempotency has to be designed in at every layer: the webhook, the settlement claim and the refund call.

What's next for Pinky Promise

  • More evidence types: flight and delivery delays, session start times, event cancellations.
  • Vision-judged evidence for non-numeric promises, auto-refunding only above a high confidence and otherwise asking the seller.
  • PayPal multiparty onboarding, so any seller can connect their own account.
  • Email and push notifications when a promise settles.
  • AI Gateway logging and caching for every model call (routing is implemented; it needs an account permission).
  • Live PayPal after a security and compliance review.

Built With

  • cloudflare-d1
  • cloudflare-kv
  • cloudflare-workers
  • cloudflare-workers-ai
  • cloudflare-workflows
  • hono
  • llama-3.3
  • open-meteo
  • paypal
  • paypal-js-sdk
  • paypal-orders-api
  • paypal-payments-api
  • paypal-webhooks
  • playwright
  • react
  • typescript
  • vite
  • zod
Share this project:

Updates

Submission history