PAYQRIS AI INTEGRATION PROMPT

<<<<<<< HEAD
You are an AI assistant helping me integrate PayQRIS (a modern payment gateway) into my application.

Before writing code:
1. Read https://payqris.id/docs for the full public documentation.
2. Read https://payqris.id/api/docs for current API metadata.
3. Read https://payqris.id/llms.txt for the AI-oriented summary.
=======
You are helping me integrate PayQRIS into an existing application.

Before writing code:
1. Read https://YOUR-DOMAIN/docs for the full public documentation.
2. Read https://YOUR-DOMAIN/api/docs for current API metadata.
3. If available, read https://YOUR-DOMAIN/docs/llms.txt for the AI-oriented summary.
>>>>>>> origin/master
4. Do not invent endpoints, fields, headers, statuses, webhook events, or response formats that are not documented.
5. Keep API keys and webhook secrets on the server. Never put them in frontend code, public repositories, or client-side environment variables.

Integration requirements:
<<<<<<< HEAD
- API authentication uses the `X-API-Key` header.
- API base URL is `https://payqris.id/api/v1`.
- Public (no-auth) API base URL is `https://payqris.id/api/public`.
- Create invoices using `POST /invoices`.
- Use `Idempotency-Key` header for each unique order and reuse the same key when retrying that order to avoid duplicate invoices.
- Public payment status is available from `GET /api/public/payment-links/:reference_id`.
- Webhook events and signature rules must follow the current documentation (`X-Signature` HMAC-SHA256 of the raw body).
- Treat webhook handling as idempotent (reply with HTTP 200).
- Handle HTTP 400, 401, 403, 404, 409, 429, 500, and 503 according to the documented behavior.
- On HTTP 429, use exponential backoff instead of rapid polling.

When generating implementation code:
- First, explain which existing files need to change.
- Reuse my project's current framework, language, database, and architecture.
- Do not rewrite unrelated parts of my project.
- Include environment variables needed for secrets.
- Include robust server-side validation, error handling, and type safety.
- Include a small test or curl example request if applicable.
- If documentation is ambiguous or missing, tell me exactly what is missing instead of guessing.
=======
- API authentication uses X-API-Key.
- API base URL is YOUR-DOMAIN/api/v1.
- Create invoices with POST /invoices.
- Use Idempotency-Key for each unique order and reuse the same key when retrying that order.
- Public payment status is available from /api/public/payment-links/:reference.
- Webhook events and signature rules must follow the current documentation.
- Treat webhook handling as idempotent.
- Handle HTTP 400, 401, 403, 404, 409, 429, 500, and 503 according to the documented behavior.
- On 429, use exponential backoff.

When generating implementation code:
- First explain which existing files need to change.
- Reuse the project's current framework, language, database, and architecture.
- Do not rewrite unrelated parts of the project.
- Include environment variables needed for secrets.
- Include server-side validation and error handling.
- Include a small test/example request.
- If documentation is ambiguous or missing, say exactly what is missing instead of guessing.
>>>>>>> origin/master

My integration goal:
[DESCRIBE WHAT I WANT TO BUILD]

My stack:
[LANGUAGE / FRAMEWORK / DATABASE]