Ready prompts for your coding agent

Integrate Fluveo payments into this app. The app sells: <what you sell>. Payment methods: <card, Pix, Boleto>.

Fluveo is a payments processor with its own /v1 API, the same for every store. One call, POST /v1/payment_intents, takes card, Pix and Boleto; only the payment method fields change. Use a currency the account accepts (default_currency on GET /v1/account names one) and the method charges in (the methods table at https://docs.fluveo.com/payments.md).
Read these before you write code, and follow them over anything you remember about other payments APIs:
- Playbook: https://docs.fluveo.com/agents/integrate.md
- Index of all pages: https://docs.fluveo.com/llms.txt
- Every endpoint and parameter that exists: https://docs.fluveo.com/openapi.json
API base: https://api.fluveo.com/v1

ALWAYS:
- Call the API over plain HTTP from server code (fetch, requests, curl), with form-encoded bodies.
- Read the secret key from the FLUVEO_SECRET_KEY environment variable and send it as "Authorization: Bearer <key>". Use only sk_test_ keys.
- Send an Idempotency-Key header on every POST. Derive it from the order and the action (order-1042-pay) and store it, so a retry reuses the same key with the same body.
- Retry with the same key on a timeout, a network error, 409, 429 or 5xx, but stop when a 500 comes back with Idempotent-Replayed: true: mark that order unknown and reconcile it by metadata.order_id, as the playbook's step 10 says.
- Write amounts in the smallest currency unit (2000 = $20.00 or R$ 20,00).
- Create the webhook endpoint with POST /v1/webhook_endpoints and store its whsec_ secret in FLUVEO_WEBHOOK_SECRET.
- Verify every webhook: read the raw body, check the Fluveo-Signature header (t=<unix>,v1=<hex HMAC-SHA256 of "t.body" keyed with the whsec_ secret>), compare every v1 in constant time and accept when one matches, reject timestamps older than 5 minutes, and skip evt_ ids you already handled.
- Mark an order paid only on a verified payment_intent.succeeded event.

NEVER:
- Never install or import a server SDK for payments, and never call another payments API host.
- Never send a header that acts for another account, transfer_data, on_behalf_of or application_fee_amount.
- Never send raw card numbers to the API. In test mode use test PaymentMethods such as pm_card_visa.
- Never send a Fluveo-Version header: every request runs in 2026-05-27.dahlia, the only version.
- Never use an endpoint or parameter that is not in openapi.json, even if another payments API has it.
- Never put a key or a whsec_ secret in code, logs, tests or commits, and never ask me to paste one into the chat.
- Never use a live key (sk_live_) and never fulfil an order on the browser redirect.

When the code is written, run these checks in test mode yourself and report each result with the ids you saw:
1. GET /v1/account answers 200 with an id that starts with mch_.
2. A payment works: a card PaymentIntent with payment_method_types[]=card, payment_method=pm_card_visa and confirm=true answers status "succeeded". If the app takes Pix or Boleto, each answers "requires_action" with its next_action, and one sent with the payer email succeed_immediately@example.com turns "succeeded" within seconds, with its payment_intent.succeeded event. Never call a /__mock/ or /v1/test_helpers/ path to pay it.
3. pm_card_visa_chargeDeclined answers 402 card_declined and the app shows an error.
4. GET /v1/events?type=payment_intent.succeeded lists the payment's event.
5. The webhook handler accepts a correctly signed body (200) and rejects a changed body or an old timestamp (400).
6. The same event delivered twice changes the order once.
7. A card refund with POST /v1/refunds is wired: it answers 200 with a re_ refund, status "succeeded", or "pending" with pending_reason insufficient_funds while the store's balance does not cover it. Both pass: charge.refunded fires, the charge shows amount_refunded, and the PaymentIntent stays "succeeded". Never send a pending refund again, and never with a new Idempotency-Key: wait for its refund.updated event.
8. The same PaymentIntent POST sent again with the same Idempotency-Key returns the same pi_ id with the header Idempotent-Replayed: true, and no second payment exists.
9. No sk_test_ or whsec_ value appears in the code, the logs or the git history.
Do not say you are done until every check passes. If something is unclear or a call fails in a way the docs do not explain, stop and tell me.