Inspiration

Online shopping is easy to take for granted when using a mouse, keyboard, or touchscreen is effortless. But for people with muscular dystrophy, limited mobility, or other disabilities, a simple purchase can require many small physical interactions: searching, opening products, comparing options, managing a cart, and completing checkout.

That led to AccessPay AI and a simple question:

What if someone could complete most of the shopping journey through conversation?

At the same time, making shopping easier should not mean giving AI control over someone's money. That shaped the central idea behind AccessPay: AI can assist throughout the shopping journey, but financial commitments require clear human authorization.

What AccessPay Does

AccessPay is a voice-first AI shopping and payment assistant.

A user can say:

"Find wireless headphones under $80."

and continue naturally with:

"Compare the first two."

"Which one is cheaper?"

"Show me something cheaper."

"Save the first one."

"Add it to my cart."

AccessPay maintains the active shopping context, so the user does not need to repeat the original request with every command.

Voice works throughout Shop, Saved, Cart, Orders, purchase review, subscriptions, and payment-related navigation. Users can also type a product query and choose from suggested searches.

Product Discovery and Conversational AI

AccessPay separates language understanding from product information.

Google Gemini interprets natural-language requests, follow-up questions, and references such as "the first one" or "something cheaper."

Channel3 supplies real commerce product data, including available product names, images, merchants, prices, and product information.

This separation allows AI to understand what the user wants without making the AI the source of product facts.

Saved Items and Searches

AccessPay separates products a user may want later from products they are preparing to purchase.

Saved products can be viewed, discussed, removed, or added individually or in groups to the cart.

AccessPay also distinguishes between Recent Searches, which are remembered automatically, and Saved Searches, which the user deliberately keeps. Searches can be run again to retrieve current product information rather than relying on old results or prices.

Cart and Checkout

The cart supports multiple products and quantities. The backend calculates the authoritative transaction amount used throughout checkout.

Before payment, AccessPay presents the items, quantities, subtotal, shipping, tax, and final total.

At this point, flexible conversational interpretation stops.

Responses such as:

"Yes."

"Okay."

"Go ahead."

do not authorize a purchase.

Instead, the user must explicitly confirm the displayed amount with a phrase such as:

"Confirm $53.99 purchase."

Only after the correct confirmation can AccessPay proceed to PayPal.

PayPal Payments

One-time purchases use the PayPal Sandbox Orders API.

The payment flow is:

Purchase Review → Exact Amount Confirmation → PayPal Order → Buyer Approval → Capture

PayPal remains responsible for buyer approval.

After a successful capture, AccessPay records the transaction and can display the PayPal Order ID and Capture ID in Order History.

Reordering also creates a new transaction. Previous authorization is never reused; the new purchase must be reviewed and confirmed again.

Subscription Safety

AccessPay handles recurring financial commitments separately from one-time purchases.

The prototype currently uses a clearly identified demo subscription catalog together with a real PayPal Sandbox subscription workflow.

Before proceeding, AccessPay displays the recurring amount and billing frequency.

Authorization must match both.

For example:

"Confirm $19.99 monthly subscription."

If the amount is wrong, the confirmation is rejected.

If the user says "yearly" when the subscription is monthly, it is also rejected.

After PayPal approval, AccessPay records the PayPal Subscription ID and subscription status separately from ordinary purchases.

This allows AccessPay to distinguish clearly between agreeing to spend an amount once and agreeing to spend that amount repeatedly.

How We Built It

The frontend uses React, TypeScript, and Vite, with the browser's Web Speech API for voice interaction.

The backend uses Python and FastAPI, with SQLite for prototype persistence.

The main integrations are:

  • Google Gemini — natural-language understanding and conversational intent
  • Channel3 — real commerce product discovery
  • PayPal Sandbox — one-time and recurring payment workflows
  • APIMatic — PayPal API context during development and developer tooling for the AccessPay Merchant API

Testing uses Pytest for backend behavior and Playwright for end-to-end application flows.

Each component has a clear responsibility: Gemini understands the request, Channel3 supplies product information, AccessPay maintains shopping and transaction state, and PayPal handles payment approval and processing.

Using APIMatic

APIMatic is used in two different ways in AccessPay.

First, I integrated the official APIMatic PayPal Context Plugin into the development workflow. It gives the AI coding environment authoritative PayPal API context and was used while validating PayPal authentication, Orders creation and capture, approval-link handling, subscription lifecycle operations, and error handling.

Second, I used APIMatic to make AccessPay itself easier for other developers to understand and integrate.

AccessPay's FastAPI backend produces an OpenAPI specification containing its shopping, cart, checkout, order, payment, subscription, and related APIs.

I validated that specification with the APIMatic CLI and imported it into APIMatic. From the real AccessPay API definition, APIMatic generated an AccessPay Merchant API developer portal containing:

  • TypeScript integration support
  • Python integration support
  • API reference documentation
  • an AccessPay Context Plugin for AI-assisted integration

This is separate from the PayPal Context Plugin used while developing AccessPay.

APIMatic is also not part of the customer's runtime payment path. Customer payments continue to go directly from AccessPay through PayPal.

AccessPay for Merchants

AccessPay is not limited to the reference shopping application.

The same capabilities are exposed through the AccessPay Merchant API, providing a path for another company to add AccessPay to an existing website or application instead of replacing its storefront.

The merchant-facing API includes capabilities for conversational shopping, product discovery, saved items and searches, cart operations, checkout, orders, payments, and subscriptions.

The architecture is:

Customer → Merchant Website or App → AccessPay API → Gemini / Commerce Services / PayPal

In this hackathon implementation, Channel3 provides the product data. A future merchant deployment could connect AccessPay to the merchant's own catalog or commerce system.

The APIMatic-generated developer portal demonstrates how developers can explore the AccessPay API, its schemas, TypeScript and Python integration options, and AI-ready context.

The Merchant API remains a prototype, not a production multi-tenant platform. Production deployment would require merchant authentication, tenant isolation, rate limiting, webhooks, monitoring, audit controls, and additional security infrastructure.

Challenges We Faced

One of the hardest technical challenges was maintaining context across voice interactions.

A phrase like:

"Compare the first two."

only works if the frontend, backend, product ordering, and active shopping session all agree on exactly what "the first two" means.

Voice navigation added another challenge because references depend on the current page. "The second one" might refer to a search result, saved item, cart item, or previous order.

Speech recognition also required work to support natural pauses without submitting incomplete commands.

PayPal redirects introduced browser-specific challenges involving application state, consistent origins, and microphone permissions. AccessPay had to ensure that returning from PayPal did not automatically activate the microphone.

Another challenge was integrating a large API surface with developer tooling. The AccessPay OpenAPI definition had to be cleaned and validated so APIMatic could correctly understand its routes, schemas, operation IDs, and descriptions.

Finally, financial authorization required a fundamentally different approach from conversational AI. Natural language benefits from flexibility; financial consent benefits from precision. Subscription payments extended that requirement from confirming an amount to confirming both an amount and a billing frequency.

What We Learned

The biggest lesson was that useful agentic commerce does not require giving AI unlimited autonomy.

AI is valuable for reducing the effort involved in understanding intent, maintaining context, searching, comparing, navigating, and preparing transactions.

But irreversible financial actions need stronger boundaries.

I also learned that accessibility cannot be added only at the beginning of an experience. Voice interaction has to remain useful as the user moves from discovery to saved products, cart management, checkout, payment, and order history.

And building AccessPay as an API showed another possibility: accessibility features do not have to remain confined to a single application. They can be designed as capabilities that other developers can integrate into their own products.

The Bigger Idea

The goal of AccessPay is not to build another online store.

It is to make online commerce require less precise physical interaction while keeping financial decisions understandable and firmly under the user's control.

The reference application demonstrates that experience directly.

The AccessPay Merchant API and APIMatic developer portal demonstrate how the same capabilities can extend beyond one application and become an accessibility and commerce layer for other companies.

The principle remains simple:

AI can make shopping easier. The human still decides when money is spent.

Built With

  • apimatic
  • apimatic-context-plugin
  • channel3
  • fastapi
  • google-gemini
  • openapi
  • paypal
  • paypal-orders-api
  • paypal-subscriptions-api
  • playwright
  • pydantic
  • python
  • react
  • rest-api
  • sqlite
  • typescript
  • vite
  • web-speech-api
Share this project:

Updates

Submission history