The problem PayDI solves

PayDI solves a core merchant pain point in crypto payments: merchants want to price in familiar fiat (USD/AED) while accepting on-chain payments without building pricing, wallet UX, and settlement logic from scratch.
Instead of forcing teams to wire together oracles, wallet flows, session tracking, and status handling manually, PayDI provides a Stripe-like flow on ADI Chain: create a payment session in fiat, render an embeddable checkout component, and receive on-chain settlement updates.

What people can use it for:

• E-commerce stores that want to price products in USD/AED and accept ADI (or ADI-chain tokens).
• SaaS platforms that need low-friction one-time checkout with wallet support and status callbacks.
• Web apps that need cross-device checkout (desktop storefront, mobile wallet payment via QR).
• Merchant teams that want a dashboard for API keys, settlement configuration, and payment history instead of raw chain plumbing.

How it makes existing tasks easier/safer:

• Faster integration: a merchant can embed a widget and start accepting payments in minutes.
• Lower implementation risk: built-in session lifecycle states (pending/confirmed/failed/expired), wallet connect, fallback paths, and callbacks.
• Operational clarity: merchant config + dashboard visibility + standardized API surface reduce integration mistakes and support burden.

Challenges I ran into

One recurring challenge was state synchronization between wallet authentication and dashboard data fetching.
Initially, after connecting a wallet, merchants sometimes had to manually refresh before sessions/config appeared because auth data landed in

localStorage

after the UI had already evaluated connection state.

I fixed this by introducing an explicit auth-change event flow: when SIWE verify/signout updates storage, the app emits an auth-changed signal, and pages reactively refetch with the latest token.
That removed the reload requirement and made post-connect UX immediate and predictable.

A second hurdle was styling in embedded contexts: converting widget UI to host-dependent utility classes caused layout breakage in environments where those classes were not compiled.
I resolved it by making the widget styling self-contained again for reliable embedding, while still keeping consistent aesthetics and removing placeholder/filler assets.

Use of AI tools and agents

This project went all-in on AI-native building using Claude Code, Codex, and OpenCode with parallel agents running across multiple workstreams.
I used these agents for implementation, UI refactors, bug triage, integration documentation, and consistency passes across dashboard, widget, and testsite.

AI-generated outputs were integrated into a workflow with guardrails:

• Human-reviewed architecture and API decisions.
• Iterative code changes with build/test verification.
• Prompted generation of agent-readable docs (

  /llms.txt

  ) so coding agents can integrate PayDI correctly with minimal ambiguity.

Within the system, this creates a practical loop:
PayDI exposes deterministic integration surfaces (API + widget + docs), and AI agents consume those instructions to automate merchant integration tasks.
That improves developer onboarding and reduces implementation errors for teams adopting crypto payments.

PayDI is also intentionally built to be LLM-integratable:

/llms.txt

provides a canonical machine-readable integration guide, and the landing page includes a one-click “Copy instructions for your Agent” CTA so developers can hand integration tasks directly to their coding assistants.