# Build a Hosted-Checkout E-commerce Vertical Slice

Amo ID: AMO-P-000348
Version: 1.0.0
Public URL: https://amo.ng/prompts/build-hosted-checkout-ecommerce-vertical-slice

Summary: Implement one approved catalog-to-order journey using hosted checkout in a payment sandbox, with server-verified prices, signed webhooks, order-state integrity, reconciliation, and disabled fulfilment.

Use this for: Use this for implementing and testing a bounded catalog, cart, order, hosted-checkout, verified-webhook, and reconciliation path without handling card details or activating live commerce.

Category: Codex & Coding
Tool: Codex
Difficulty: Expert
Prompt type: feature build

## Best Use Cases

1. Implementing a single-product or small approved catalog journey with hosted payment checkout in a sandbox.
2. Connecting an existing cart and order model to a hosted provider while keeping card collection off-site.
3. Testing signed webhooks, duplicate and out-of-order events, and order-state reconciliation before release.
4. Building a commerce vertical slice with fulfilment and customer messaging disabled behind a reversible control.

## Prompt Body

Implement one bounded catalog-to-order journey using the approved hosted-checkout provider in its sandbox. Build the catalog presentation, cart integrity, local order, hosted session, return handling, verified webhook transitions, and reconciliation required by the supplied contract. Keep payment-card collection on the provider’s hosted interface and keep production payment, fulfilment, and customer messaging disabled.

Treat this as a medium-risk implementation because it changes order state and integrates with a payment service. Do not expand it into a complete online store, marketplace, subscription platform, inventory system, refund service, dispute process, or administration suite.

## Required inputs

Approved catalog, cart, and order contract:
{{approved_catalog_cart_and_order_contract}}

Repository and stack context:
{{repository_and_stack_context}}

Hosted-payment sandbox and webhook contract:
{{hosted_payment_sandbox_and_webhook_contract}}

Test products and fulfilment boundaries:
{{test_products_and_fulfilment_boundaries}}

Acceptance criteria and authorized scope:
{{acceptance_criteria_and_authorized_scope}}

## Evidence and assumption rules

1. Classify material statements as supplied fact, repository observation, provider-contract evidence, execution evidence, assumption, conflict, missing information, or unresolved uncertainty. Cite files, symbols, schema objects, product fixtures, sandbox object or event identifiers, commands, and test output.
2. Do not invent products, prices, quantities, availability, currencies, taxes, discounts, delivery charges, refund rules, legal terms, order states, provider capabilities, webhook behavior, fulfilment behavior, test results, credentials, or approvals.
3. Treat browser cart values and return-page parameters as untrusted. Resolve products and calculate approved prices, discounts, taxes, delivery, currency, and payable totals server-side.
4. The browser success return is navigation evidence, not authoritative payment confirmation. Mark an order paid only from the approved authenticated provider evidence, normally a verified webhook or separately approved server-side verification.
5. Never request, receive, log, store, or reproduce raw card details. Refer to provider credentials and webhook secrets by configuration name only; never include their values.
6. Use synthetic customers, approved test products, sandbox provider objects, fake messages, and disabled fulfilment. Do not use live API keys, production webhooks, or real customer data.
7. Preserve unrelated repository and configuration work. Distinguish changes applied and tests executed from proposals and unverified expectations.

## Authorization boundaries

- Implementation requires an authorized repository, approved catalog and order rules, hosted-provider sandbox access already configured securely or a mockable contract, test products, and permission to change the bounded slice.
- Inspect only the supplied workspace, schemas, interfaces, sandbox evidence, configuration references, fixtures, and command output. Do not imply access to production payment, fulfilment, tax, inventory, email, or deployment systems.
- Change only approved files, schema objects, sandbox configuration references, and test fixtures. Keep production credentials absent, provider live mode disabled, fulfilment disabled, and customer messages routed to fakes or test sinks.
- Do not charge a customer, use live keys, replay production webhooks, activate fulfilment, send production order messages, deploy, merge, push, publish, or run destructive migrations.
- Obtain separate approval before schema changes with lock or data-loss risk, external calls outside the provider sandbox, dependency installation, financially consequential action, or production activation.
- Stop with a blocked handoff if the catalog or order contract, authoritative payment evidence, webhook-signature requirements, safe sandbox, fixtures, or execution authority is unavailable.

## Implementation method

### 1. Establish the bounded commerce contract

Restate the approved user journey from catalog view through cart, local order creation, hosted-checkout session, success or cancellation return, webhook processing, final local state, and disabled fulfilment handoff.

List included products, quantity and availability rules, currency, pricing authority, taxes, discounts, delivery behavior, order states, payment states, provider events, test fulfilment boundary, and acceptance criteria. Preserve unresolved commercial, tax, delivery, legal, or refund rules as blockers.

### 2. Inspect the repository and payment boundary

Inspect the working-tree state, framework and runtime, product and price source, routes, cart state, validation, authorization, order schema, transactions, provider adapter or SDK, checkout-session code, success and cancellation routes, webhook route and middleware, raw-request handling, signature verification, idempotency storage, queues, fulfilment boundary, notifications, tests, feature flags, and logs.

Confirm the provider sandbox environment and credential-reference names without revealing values. Identify the authoritative payment-confirmation mechanism and current state-transition rules. Record unavailable or unverified surfaces.

### 3. Set a concise implementation checkpoint

Map each requirement to files, symbols, schema or configuration changes, state transitions, provider operations, tests, fakes, and rollback actions. Identify the precise external calls allowed in the sandbox and the evidence they should produce.

If an approved product/price contract, editable repository, safe provider sandbox or mock, signed-webhook contract, or testable order model is unavailable, stop. Do not substitute a design document and claim implementation.

### 4. Implement catalog and cart integrity

Render only approved active test products and fields. Use stable server-side product and price identifiers. Validate quantity, availability, currency, discount eligibility, tax and delivery inputs against the supplied contract.

Treat cart state as a request to purchase, not a financial authority. Re-read current approved product and price data on the server before local order or checkout-session creation. Reject missing or inactive products, invalid quantities, stale or tampered prices, currency mismatches, and unsupported discounts visibly.

Do not silently substitute a different product, price, currency, tax, or delivery rule. Record a conflict when approved sources disagree.

### 5. Implement local order creation

Implement the approved order and payment states with explicit allowed transitions. Create a local order from the server-verified cart inside the appropriate transaction. Record immutable line-item descriptions, unit amounts, quantities, currency, approved adjustments, total, and provider correlation fields required by the contract.

Use an idempotency identity for repeated checkout submissions so one user action cannot create uncontrolled duplicate orders or sessions. Do not mark the order paid or start fulfilment during session creation.

### 6. Implement hosted-checkout session creation

Create the provider sandbox session server-side using approved price references or server-calculated amounts, metadata, success URL, cancellation URL, and provider idempotency support where specified. Ensure card collection, authentication, and payment-method handling remain on the hosted provider interface.

Handle provider validation errors, timeouts, rate limits, unavailable service, and ambiguous completion. Persist enough non-sensitive correlation evidence to look up the sandbox result before retrying. Never expose secrets or sensitive provider responses to the browser.

### 7. Implement success and cancellation returns

Treat the success return as a pending-status display until authoritative provider evidence has updated the order. Do not trust query parameters or the browser session to confirm payment.

Provide clear pending, paid, failed, cancelled, expired, and unavailable states according to the approved model. A cancellation return must not overwrite an authoritative successful payment event. Repeated return-page access must be safe and side-effect free.

### 8. Implement webhook verification and event processing

Preserve the raw request body where the provider’s signature protocol requires it. Verify the signature, timestamp tolerance, environment, relevant account, event type, object identity, order correlation, currency, and amount before changing state.

Reject invalid signatures and mismatched objects without applying business effects. Store a stable provider event identity and payload fingerprint or equivalent approved evidence so duplicate delivery is idempotent and conflicting reuse is visible.

Process supported events through explicit order-state transition rules. Handle duplicate, delayed, and out-of-order events without regressing a terminal state or duplicating effects. A verified event may authenticate its contents; it does not authorize behavior outside the approved transition table.

### 9. Keep fulfilment and messages disabled

Represent the approved fulfilment handoff behind a disabled feature flag, fake queue, test adapter, or explicit non-production terminal state. Route order messages only to fakes or approved test sinks.

Record that a fulfilment action would be eligible only after authoritative payment evidence and required owner controls. Do not ship, grant entitlements, create live inventory movements, or contact customers.

### 10. Implement recovery and reconciliation

Handle failed or abandoned checkout, failed session creation, webhook processing failure, ambiguous provider response, database failure, queue failure, delayed events, and local/provider disagreement.

Provide an idempotent recovery path that checks provider sandbox state before retrying uncertain session or event work. Reconcile local order ID and state, provider object and event state, amount, currency, event history, and fulfilment-disabled state. Do not force a match by overwriting unexplained differences.

### 11. Run the commerce test suite

Use approved test products, synthetic customers, provider sandbox fixtures, and fake fulfilment and notifications. Execute applicable tests for:

- valid cart and hosted-session creation;
- tampered price or quantity;
- missing or inactive product;
- currency mismatch and invalid discount;
- duplicate checkout submission;
- failed, timed-out, and ambiguously completed session creation;
- abandoned or cancelled checkout;
- successful and failed sandbox payment;
- invalid webhook signature and malformed raw body;
- duplicate, out-of-order, and delayed webhook events;
- amount, currency, environment, account, or order mismatch;
- retry after uncertain completion;
- return-page access before webhook completion and repeated return access;
- local/provider reconciliation difference;
- fulfilment and production messaging remaining disabled;
- feature flag off and rollback behavior.

Record exact commands, provider sandbox or fixture identifiers, expected transitions, observed local rows, provider evidence, queued or blocked effects, exit states, and failures. Do not claim production behavior from sandbox results, or PCI, legal, security, or operational compliance from these tests.

### 12. Reconcile acceptance and prepare rollback

Map every acceptance criterion to applied code and execution evidence. Preserve failed or unrun tests. Provide rollback for application files and configuration, schema constraints, pending sandbox orders, event records, queues, feature flags, and the disabled fulfilment boundary.

Release remains subject to security review and release-owner approval. Live credentials, production webhooks, fulfilment activation, refunds, subscriptions, disputes, and operational commerce controls remain outside this Prompt.

## Stop conditions

Stop with a precise blocked handoff when:

- approved products, prices, currency, taxes, discounts, delivery, order states, or payment authority are missing or conflicting;
- an authorized repository, safe database, hosted-provider sandbox or mock, or signed-webhook contract is unavailable;
- raw card details, live keys, real customers, production webhooks, charges, fulfilment, or customer messaging would be required;
- the browser return would be the only proposed payment authority;
- signature, amount, currency, environment, account, or order correlation cannot be verified;
- duplicate and out-of-order events cannot be processed idempotently;
- local and provider sandbox state cannot be reconciled after an uncertain result;
- a destructive schema change lacks approval and rollback evidence;
- critical payment-state or fulfilment-disablement tests fail outside a bounded correction.

## Output contract

Return these sections:

1. **Commerce-slice implementation status**: `Implemented and tested in the authorized sandbox`, `Partially implemented`, or `Blocked`. Separate inspected, applied, executed, demonstrated, and unverified work.
2. **Evidence and assumptions register**: source, classification, location, conflict or limitation, implementation effect, and required owner.
3. **Catalog-to-order traceability**: requirement, product or price authority, interface, file and symbol, implementation, test evidence, and gap.
4. **Repository and configuration change manifest**: file, schema, configuration or adapter item, change, financial or side-effect risk, applied state, and rollback.
5. **Order-state transition table**: current state, event or actor, authenticity and preconditions, next state, prohibited regression, side effect, and evidence.
6. **Price and cart-integrity test record**: product and cart case, server-side authority, manipulation, expected rejection or amount, observed result, and evidence.
7. **Hosted-checkout and webhook evidence**: sandbox object or event, signature and correlation checks, amount and currency, local transition, execution result, and evidence.
8. **Idempotency and event-ordering matrix**: request or event identity, duplicate or ordering scenario, transaction rule, expected result, observed state and effects, and status.
9. **Sandbox order/payment reconciliation**: local order, provider object, amount, currency, local state, provider state, event history, difference, disposition, and owner.
10. **External-side-effect record**: provider call, fulfilment, message, queue, test target, observed effect, prohibited production effect, and disabled-state evidence.
11. **Rollback and release-owner handoff**: feature disablement, schema and pending-order considerations, webhook containment, reconciliation, security review, release prerequisites, and rollback verification.
12. **Completion statement**: reconcile every acceptance criterion and end with the smallest safe next action.

Completion requires actual authorized code and configuration changes for the bounded catalog-to-order path, server-side price integrity, a hosted sandbox checkout, verified-webhook state changes, duplicate and out-of-order event evidence, local/provider reconciliation, proof that fulfilment and customer messaging remain disabled, and a viable rollback. Do not claim that a complete store was built or that payments, security, PCI, legal compliance, production readiness, or deployment are established beyond the evidence.

## Variables to Replace

1. approved_catalog_cart_and_order_contract
2. repository_and_stack_context
3. hosted_payment_sandbox_and_webhook_contract
4. test_products_and_fulfilment_boundaries
5. acceptance_criteria_and_authorized_scope

## How to Use

Run this Prompt in Codex with the authorized commerce repository, approved product, pricing, cart and order rules, hosted-payment sandbox contract, test products, disabled fulfilment boundary, acceptance criteria, and exact file and command permissions. Configure credentials outside the Prompt and provide only reference names; never paste card details, live keys, production webhooks, or real customer records. Ask Codex to implement only the bounded vertical slice, run sandbox and local tests, reconcile provider events to local orders, and prove that fulfilment and customer messaging remain disabled. The security reviewer and release owner must review payment-state evidence, migrations, rollback, and live-environment prerequisites before release.

## Example Use Case

A small retailer has approved three sandbox products, one currency, fixed delivery, and no discounts or refunds for the initial slice. Codex implements server-verified cart totals, local pending orders, hosted sandbox sessions, pending success pages, signed webhook transitions, duplicate and out-of-order event handling, and sandbox reconciliation. Tests use synthetic buyers and fake fulfilment, while live keys, customer messages, and production activation remain unavailable.

## Tags

1. codex
2. Codex & Coding
3. feature-build
4. ecommerce
5. checkout
6. payment-integration
7. webhooks
8. idempotency
9. duplicate-events
10. transaction-integrity
11. sandbox-testing
12. data-reconciliation

## Dates

Published: 2026-09-09
Updated: 2026-09-09