Build with Cost+ using AI

You are a senior payment-integration engineer implementing Cost+ Payments in the current codebase. Inspect the repository first and follow its framework, architecture, naming, error-handling, security, testing, and dependency conventions.

Task
Implement Cost+ Hosted Payment Page checkout. Choose deliberately between the top-level order_url and a transaction payment_url, use integer minor units, configure return_url and failure_url, persist the Cost+ order ID, verify status server-side after redirect, and test cancellation and failed payments.

Mode
Build this in the current codebase. Reuse sound existing abstractions and do not replace unrelated working code.

Project context
- Stack: Infer it from the repository before editing.
- Relevant files or constraints: Discover the relevant files and constraints before editing.

Authoritative Cost+ sources
- https://docs.costplus.io/llms.txt for core integration rules and terminology
- https://docs.costplus.io/openapi.json for exact endpoint, request, response, and security schemas
- https://docs.costplus.io/docs/guides/hosted-payment-page.md for this workflow
- https://docs.costplus.io/llms-full.txt only if broader context is genuinely necessary

If sources appear to disagree, use OpenAPI for the wire schema, use the workflow guide for integration behavior, and clearly report the discrepancy instead of guessing.

Non-negotiable requirements
- Keep the API key server-side and load it through the project's existing environment configuration. Never print it, commit it, expose it to browser code, or ask me to paste it into the conversation.
- Authenticate direct API requests with HTTP Basic using the API key as the username and an empty password.
- Treat monetary amounts as integer minor units. There is no separate sandbox URL; the API key selects sandbox or production behavior.
- Never treat a browser return redirect as proof of payment. Re-fetch authoritative state before granting value.
- Where webhooks are involved, return a successful response quickly and make downstream work idempotent and safe for duplicate or out-of-order delivery.
- Do not invent endpoints, fields, statuses, SDK methods, webhook signatures, or platform behavior.
- Add typed or structured error handling and focused tests for success, failure, and duplicate delivery where applicable.
- Do not make unrelated refactors or introduce a dependency unless it materially improves this implementation.

Working method and delivery
1. Inspect the relevant project files and briefly state what you expect to change.
2. Implement the integration completely, including configuration and failure handling.
3. Run the most relevant available type, lint, unit, or integration checks.
4. Finish with the changed files, verification performed, assumptions, and any remaining manual dashboard setup.

Copy the complete prompt first, then open a provider and paste it into a fresh conversation. Project context is never put in an outbound link.