Take my money

Upgrade now. Keep every paid day.

Comment

Live demo: https://take-my-money-psi.vercel.app

Source code: https://github.com/mitiay7/take-my-money

Inspiration

I subscribed to ChatGPT through Apple and later wanted to move to a direct subscription.

The problem was surprisingly simple: I was ready to upgrade and pay more, but the billing architecture required me to wait until the existing App Store subscription period ended. Starting a second subscription immediately could also create overlapping subscriptions and duplicate charges.

This is a broader problem in subscription products. The customer has already decided to buy, but separate billing providers do not share subscription value or state.

Take my money started with one question:

What if the unused value of an existing subscription could follow the user to the new billing provider?

What it does

Take my money demonstrates a complete provider-neutral subscription migration mechanism.

The application:

  1. receives evidence of an existing externally billed subscription;
  2. extracts subscription information from a synthetic receipt;
  3. treats the extracted data as unverified evidence;
  4. verifies the source subscription through an authoritative provider adapter;
  5. calculates the exact unused value of the paid period;
  6. converts that value into a one-time migration credit;
  7. applies the credit to a new direct subscription;
  8. executes the migration through a transactional state machine;
  9. prevents the same source transaction from being migrated twice;
  10. records every financial state change in an append-only ledger and audit trail.

The result is an immediate upgrade without discarding value the user has already paid for.

Take my money does not attempt to transfer funds out of Apple or issue an Apple refund. Instead, it demonstrates how the destination provider could recognize the remaining service value and issue an internal migration credit.

User experience

The demo begins with an active subscription billed through an external provider.

The user can see:

  • the current plan;
  • the original amount paid;
  • the paid subscription period;
  • the renewal date;
  • the remaining paid time;
  • the target direct plan.

A synthetic subscription receipt is analyzed and normalized. The source subscription is then independently verified by a sandbox provider adapter.

The application presents a transparent calculation showing:

  • original subscription value;
  • used and unused time;
  • unused subscription value;
  • migration credit;
  • target-plan price;
  • amount due today.

After confirmation, the user can watch the migration progress through credit reservation, target-subscription creation, credit commitment and source-transaction consumption.

A technical system view exposes the state machine, credit ledger, audit events, idempotency protection and duplicate-migration rejection.

How it works

The financial calculation is fully deterministic.

Take my money stores money as integer minor units rather than floating-point numbers. Subscription periods are calculated using exact UTC timestamps instead of assuming that every month contains thirty days.

The migration process uses an explicit state machine:

DRAFT
→ SOURCE_VERIFIED
→ QUOTE_CREATED
→ USER_CONFIRMED
→ CREDIT_RESERVED
→ TARGET_SUBSCRIPTION_CREATED
→ CREDIT_COMMITTED
→ SOURCE_CONSUMED
→ COMPLETED

Every migration quote is immutable and expires after a configured period.

Confirmation is idempotent. Repeating the same request returns the existing result rather than creating another subscription or credit.

The source transaction can be consumed only once. Concurrent attempts are protected at the database level.

If an external operation returns an unknown result, reconciliation can inspect provider state and safely resume or restore the operation.

How GPT-5.6 is used

The project implements GPT-5.6 in two deliberately constrained areas. Live model calls run only when ENABLE_AI=true and a server-side OPENAI_API_KEY is configured. The current public deployment intentionally exposes the deterministic fallback because no deployer API key is installed.

1. Structured receipt extraction

When enabled, GPT-5.6 uses vision to inspect a version-controlled synthetic subscription receipt and returns structured fields such as:

  • provider;
  • product;
  • price;
  • currency;
  • purchase date;
  • expiration date;
  • transaction reference.

This output is treated only as unverified evidence.

The model output never becomes an authoritative billing record. The subscription must still be verified through the provider adapter before a credit can be issued.

2. User-facing explanations

When enabled, GPT-5.6 explains an already verified deterministic calculation in clear language.

It can also explain unusual states such as:

  • an expired subscription;
  • a previously refunded transaction;
  • billing retry;
  • possible duplicate billing;
  • an already migrated transaction.

GPT-5.6 never:

  • calculates monetary values;
  • determines financial eligibility;
  • authorizes a credit;
  • changes migration state;
  • creates a subscription;
  • executes a payment.

If GPT-5.6 is unavailable, the financial flow continues working with a deterministic explanation fallback.

How Codex was used

The project was built from an empty repository through an extended Codex development session.

Codex helped:

  • turn the initial product idea into an implementation specification;
  • scaffold the full-stack application;
  • design the provider-neutral architecture;
  • isolate the framework-independent billing core;
  • implement integer-based monetary arithmetic;
  • create the subscription migration state machine;
  • design idempotency and concurrency protection;
  • implement the credit ledger and audit trail;
  • build provider adapters and deterministic fixtures;
  • integrate GPT-5.6 vision and Structured Outputs;
  • generate unit, integration and end-to-end tests;
  • review security and trust boundaries;
  • iterate on the user interface;
  • create the presentation route;
  • design a reusable scene-planning model for product demos;
  • inspect prerecorded narration and derive the video timeline from actual audio durations;
  • automate the browser demo using Playwright;
  • synchronize prerecorded narration with the browser flow;
  • assemble audio, captions and browser footage with FFmpeg;
  • render and automatically validate the final competition video.

The most important human product decision was to reject the tempting but inaccurate idea of presenting this as an Apple refund mechanism.

Instead, the project was designed as a migration-credit system with a strict separation between:

  • untrusted AI extraction;
  • authoritative provider verification;
  • deterministic financial logic;
  • transactional execution.

Codex accelerated implementation and testing, while product boundaries, financial invariants and the trust model remained explicit design decisions.

Development resources and cost

My included subscription usage limits had already been exhausted on other projects before work on Take my money began.

The project was therefore developed using additional paid credits. The total incremental cost of the Codex and GPT-5.6 development work was approximately 30 US dollars.

This included iterative implementation, architecture work, code generation, debugging, automated testing, security review, interface refinement and the automated demo-video pipeline.

I am including this detail for transparency and as a practical indication of the cost of building the complete working prototype with Codex and GPT-5.6.

Technical implementation

Take my money is a full-stack web application built with:

  • Next.js;
  • React;
  • TypeScript;
  • Tailwind CSS 4;
  • Zod 4;
  • Drizzle ORM;
  • PostgreSQL 17 locally and Neon PostgreSQL in production;
  • OpenAI Responses API;
  • GPT-5.6;
  • Playwright;
  • Vitest;
  • FFmpeg;
  • Docker for local PostgreSQL and integration tests;
  • Vercel;
  • GitHub Actions.

The architecture separates:

  • the consumer interface;
  • the deterministic billing core;
  • source subscription providers;
  • target billing providers;
  • the AI extraction and explanation layer;
  • the credit ledger;
  • the migration state machine;
  • the audit system.

Provider integrations are represented through replaceable adapters. The public demo uses synthetic data and sandbox implementations so judges can test it without a real Apple account, credit card or ChatGPT subscription.

Security and correctness

Financial data sent by the browser is never trusted as authoritative.

The backend independently verifies subscription state and calculates all monetary values.

The project includes:

  • integer monetary arithmetic;
  • exact UTC period calculations;
  • schema validation;
  • expiring immutable quotes;
  • idempotency keys;
  • transaction-consumption constraints;
  • concurrent-request protection;
  • append-only ledger entries;
  • append-only audit events;
  • deterministic fallback behavior;
  • sanitized logs;
  • synthetic receipt data;
  • no real payment credentials;
  • no real subscription modification.

Private transaction identifiers and personal account information are not sent to GPT-5.6.

Challenges

The largest challenge was designing a credible prototype across two billing systems that do not actually share money, transactions or subscription state.

It would have been easy to build only a visual prorating calculator. That would not solve the real engineering problem.

The project instead had to answer harder questions:

  • What is the authoritative source of subscription truth?
  • How is unused value calculated without rounding errors?
  • How is a credit reserved and committed exactly once?
  • What happens when subscription creation succeeds but the response is lost?
  • How is the same source transaction prevented from being migrated twice?
  • What information may safely be delegated to an AI model?
  • How can the product remain understandable to a normal user?

The solution combines a simple consumer experience with a transactional backend and clearly defined trust boundaries.

Accomplishments

The project demonstrates considerably more than a prorating formula.

It includes:

  • an end-to-end working subscription migration flow;
  • a production-ready GPT-5.6 image-extraction path with Structured Outputs and an honest deterministic public fallback;
  • authoritative provider verification;
  • deterministic financial calculations;
  • a transactional migration state machine;
  • an append-only credit ledger;
  • an append-only audit trail;
  • idempotent execution;
  • duplicate-migration protection;
  • reconciliation logic;
  • failure and edge-case scenarios;
  • an inspectable technical system view;
  • automated browser testing;
  • an automated demo-video generation pipeline.

A second product emerged while preparing the submission: a reusable system for planning, recording and rendering product demos. It reads separately generated narration clips, measures their real durations, creates a shared scene timeline, drives the application through Playwright, records the browser, assembles the audio and captions with FFmpeg, and validates the finished video automatically. The same pipeline can be reused for future product launches, release demos and technical walkthroughs. It may even be more broadly useful than the billing prototype itself — although I am not completely sure about that yet.

The most important accomplishment is that the product remains easy to understand while exposing the technical depth required for a trustworthy billing system.

What I learned

AI is valuable in financial products when it is placed at the correct boundary.

GPT-5.6 is effective at understanding unstructured evidence and explaining complex results. It should not be responsible for arithmetic, financial authorization or transaction state.

I also learned that subscription portability is not fundamentally a refund problem. It is a value-recognition and transactional-consistency problem.

A credible solution requires both a consumer-friendly product experience and strict backend invariants.

Potential impact

Subscription fragmentation affects users across mobile app stores, web billing platforms, annual plans, family plans and business subscriptions.

A reusable migration-credit mechanism could help subscription businesses:

  • convert users who are already ready to upgrade;
  • reduce duplicate charges;
  • reduce support requests;
  • lower involuntary churn;
  • make billing-provider transitions less frustrating;
  • preserve trust during plan changes.

The initial demo focuses on a synthetic mobile-app-store-billed consumer subscription, but the architecture is provider-neutral.

The same mechanism could support:

  • Google Play to web;
  • monthly to annual;
  • personal to business;
  • consumer to enterprise;
  • regional billing migrations;
  • bundled subscription upgrades.

What is next

A production implementation would add:

  • real App Store Server API verification;
  • Google Play verification;
  • destination-provider billing integration;
  • tax-aware credit policies;
  • currency conversion and locked exchange rates;
  • fraud and abuse controls;
  • customer-support review tools;
  • production reconciliation workers;
  • account entitlement integration;
  • finance and legal policy configuration.

The long-term goal is a common subscription-portability layer that allows customers to change billing systems without losing already purchased value.

Disclaimer

Take my money is an independent prototype created for OpenAI Build Week.

It is not an official OpenAI, Apple or App Store billing product.

The public demo does not:

  • issue real refunds;
  • cancel real subscriptions;
  • charge real payment methods;
  • create real ChatGPT subscriptions;
  • modify real Apple transactions;
  • transfer funds between billing providers.

All subscription, receipt and payment data shown in the demo is synthetic.

Built With

Share this project:

Updates

Submission history