> For the complete documentation index, see [llms.txt](https://hot-labs.gitbook.io/hot-pay/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hot-labs.gitbook.io/hot-pay/use-with-lovable.md).

# Use with Lovable

### Example prompt to add crypto payments for online ticket service

Don’t forget to create items in [pay.hot-labs.org](https://pay.hot-labs.org) and attach merchant links to the prompt 

{% embed url="<https://youtu.be/_RiAVGLmT80>" %}

```

You must implement HOT Pay using a backend-confirmed payment flow.
A backend is mandatory. Do not treat frontend redirects as proof of payment.

Payment Flow

When a user selects a ticket, create an order in the backend and generate a unique memo (UUID).

Redirect the user to HOT Pay with:

item_id

amount

memo

webhook_url

HOT Pay processes the on-chain payment.

HOT Pay sends a webhook with payment status.

Only when status === "SUCCESS":

find the order by memo,

mark the order as paid,

issue a ticket to the user.

The memo is the single source of truth linking payment, order, and ticket.

Backend Responsibilities

Expose a webhook endpoint for HOT Pay.

Validate and process webhook payloads.

Ensure idempotency (do not issue multiple tickets for the same memo).

Never trust frontend redirects as payment confirmation.

Required Tables

profiles — user identity

orders — payment intent and status (memo is unique)

tickets — issued tickets after successful payment

Security & Constraints

Orders and tickets must be created or updated only by the backend.

Users can only read their own tickets and orders.

The app must not store or handle user funds.

HOT Pay is a stateless payment layer; all business logic lives in the backend.

UX Rules

After redirect back from HOT Pay, show a “payment pending / success” screen.

Tickets appear only after webhook confirmation.
```