Skip to main content

Inttegro Checkout

Inttegro Checkout is the hosted payment experience for finalized orders and Buy links. It lets customers review what they are buying, choose a supported payment method, complete required confirmation, and receive a receipt without your application collecting payment credentials directly.

Use MCP to operate hosted checkout

An authenticated AI agent can create a finalized order, send its invoice link after confirmation, and inspect or render the order while Inttegro Checkout handles the customer-facing payment flow.

MCP tools: create_order, send_order_invoice, get_order or render_order_card

Confirmed MCP actions require explicit form confirmation before Inttegro changes state.

Use this page to choose when hosted checkout fits. Use Accept payment with Inttegro Checkout for implementation steps and Orders for the exact API contract.

What Checkout does

Checkout turns a payable Inttegro resource into a customer-facing payment page.

ResourceHow Checkout uses it
OrderShows the customer snapshot, line items, total, invoice, and payment state.
Invoice URLGives the customer a hosted payment page and printable record.
Payment method settingsDetermines which payment methods can be shown and whether confirmation is required.
Customer detailsPre-fills known identity and delivery context when present.
ReceiptConfirms the final paid state after payment succeeds.

Your server remains responsible for creating the order, storing returned IDs, and checking final status. Checkout owns the customer-facing payment UI.

How the flow works

  1. Your server creates an order and finalizes it, or creates a purchase intent that will create an order during hosted checkout.
  2. Inttegro returns a hosted URL for the customer-facing payment experience.
  3. You redirect the customer or send them the link through a trusted channel.
  4. The customer reviews the order, selects a payment method, and completes any required confirmation.
  5. Your application looks up the order and waits for a final payment state.
  6. After payment succeeds, you fulfill the order and optionally send a receipt.

Do not treat a browser redirect as payment proof. Always verify the order through the API before fulfilling goods or services.

When to use hosted checkout

Hosted checkout is the default choice when you want to ship quickly, reduce payment-surface risk, and avoid maintaining payment-provider-specific UI.

It fits especially well for:

  • invoice-style checkout;
  • Buy links and campaign links;
  • mobile money payment confirmation;
  • teams that do not want payment credentials in their frontend;
  • merchants that need a printable customer invoice; and
  • workflows where payment can happen after the order is finalized.

Build a custom checkout only when the payment UI must stay fully embedded in your product, when you need unusual multi-step business logic before payment starts, or when the customer experience cannot leave your domain.

Finalized orders can expose hosted invoice formats, including a web URL and a PDF URL. Treat these links as sensitive customer data. They do not require your secret API key, and anyone who receives the link can view the invoice while it is usable.

Configure checkout redirects when creating or updating the order:

SettingUse
checkout_settings.redirect_urlSend customers back to your product after successful payment.
checkout_settings.cancel_urlGive customers a clear path when they cancel or abandon payment.

Redirects improve customer experience, but they are not the settlement record. Use Lookup an order to confirm status.

Status and confirmation

Order status and payment status are separate. An order can be finalized and still require payment; a payment can require customer action before it can finish.

When payment.next_action is present, show or send the required customer step. For mobile money, that may mean waiting for the customer to approve a prompt or submit a token. Poll at a reasonable interval, or refresh status when the customer returns to your product.

Use the order as the source of truth:

  • requires_payment means the order still needs collection.
  • paid means payment succeeded but fulfillment may not be complete.
  • completed means your system has recorded fulfillment.
  • canceled and expired are terminal outcomes.

Where MCP helps

MCP is useful for assisted operations around hosted checkout:

  • create a draft or finalized order from catalog product and price IDs;
  • send an invoice link to the order customer after confirmation;
  • look up the current order state; and
  • render the order as a compact status card for support or sales teams.

MCP does not replace your checkout backend. Confirmed actions still require explicit approval, and the MCP create_order tool does not execute payment.

Implementation checklist

Before relying on hosted checkout in production:

  • create orders from your server, not from an unauthenticated browser;
  • use stable idempotency keys for order creation;
  • finalize orders before sending invoice links;
  • configure redirect_url and cancel_url;
  • store the order ID and invoice URL;
  • verify payment status with order lookup before fulfillment;
  • send receipts only after payment succeeds; and
  • avoid logging invoice URLs in public analytics or client-visible traces.