Skip to main content
View as Markdown

Order now, pay later

Sometimes you need to create an order before collecting payment—maybe you're confirming inventory, waiting for manager approval, or building a pre-order system. This guide shows you how to decouple order creation from payment execution, giving you complete control over when and how you charge customers.

Use MCP for pay-later workflows

An authenticated AI agent can create an unpaid order and send its invoice when collection is due. pay_order can start a payment only after your exact confirmation; get_order tracks the result.

MCP tools: create_order, send_order_invoice, pay_order or get_order

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

How it works

The standard payment flow combines order creation and payment into one step, but Inttegro lets you split them apart. First, create an order with executePayment: false (or omit it entirely) to capture the customer's intent without charging them. Later, when you're ready, call /orders/pay to initiate the charge, then confirm it with an OTP as usual. This pattern gives you flexibility while maintaining a complete audit trail from order creation through final payment.

Step 1: create the order without payment

Create the order exactly as you would for immediate payment, but set executePayment: false or leave out payment method details entirely. Inttegro creates the order, assigns it an ID, and saves all the details—but doesn't contact the payment provider yet. The order status starts at Inttegro.OrderStatuses.Preparing, waiting for you to execute payment later.

Create order

POST/orders/create
SDK versionv12.0.0
import * as Inttegro from '@inttegro/inttegro-sdk'

const inttegro = new Inttegro.InttegroClient({
  apiKey: process.env.INTTEGRO_API_KEY!,
})
const result = await inttegro.orders.create({
  requestMeta: {
    idempotencyKey: "order_2025_001",
  },
  executePayment: false,
  customerData: {
    name: "Gloria Kesewaa",
    emailAddress: "[email protected]",
    phoneNumber: "+233544998605",
  },
  lineItems: [
    {
      type: Inttegro.LineItemTypes.Product,
      product: {
        type: Inttegro.ProductTypes.Physical,
        name: "Custom Furniture",
        quantity: 1,
        price: {
          currency: "ghs",
          value: 150000,
        },
      },
    },
  ],
})

Response​

Note

This is a partial response showing key attributes. See the complete Order object for all available fields.

Response excerpt

SDK versionv12.0.0
OrderResponse {
  order: { … },
}

Key attributes:

Step 2: execute payment when ready

When you're ready to collect payment—after confirming inventory, receiving approval, or whenever your business logic dictates—call /orders/pay with the order ID and payment method details. Inttegro contacts the mobile money provider, initiates the charge, and sends an OTP to the customer just like in the standard flow. You can provide new payment method details or reference a saved payment method if the customer has one.

Execute payment

POST/orders/pay
SDK versionv12.0.0
import * as Inttegro from '@inttegro/inttegro-sdk'

const inttegro = new Inttegro.InttegroClient({
  apiKey: process.env.INTTEGRO_API_KEY!,
})
const result = await inttegro.orders.pay({
  orderId: "or_cPxZ9kL2mQrTfVqYz1wNbMxKs8dGhJ4p",
  paymentMethodData: {
    type: Inttegro.PaymentMethodTypes.MobileMoney,
    mobileMoney: {
      network: Inttegro.MobileMoneyNetworks.MTN,
      accountNumber: "0544998605",
    },
  },
})

Response​

Note

This is a partial response showing key attributes. See the complete Order object for all available fields.

Response excerpt

SDK versionv12.0.0
OrderResponse {
  order: { … },
}

What changed:

Step 3: confirm payment with OTP

From here, the flow is identical to standard payments. The customer receives an OTP via SMS, enters it in your app, and you submit it to confirm the payment. Inttegro verifies the code, charges the mobile money account, and moves the order to Inttegro.OrderStatuses.Paid status.

Note

Confirmation is bound to one order, payment, and confirmation request. Use

payment.id

as

paymentId

and

payment.nextAction.confirmPayment.id

as

confirmationId

, then submit those values with

orderId

and token. See Confirm a payment for complete SDK examples.

Common use cases

The create and pay operations above stay the same across these workflows. What changes is the business condition that decides when your application pays or cancels the order.

Pre-orders with inventory confirmation​

Create the unpaid order when the customer places the pre-order and store its ID with your inventory reservation. Pay it after stock is confirmed. If the item is unavailable, cancel the order and tell the customer instead of leaving an open order behind.

Manager approval workflows​

Create the unpaid order before sending it through your approval process. Keep the Inttegro order ID with the approval record, then pay only after approval. Cancel declined requests so the order's state agrees with your internal record.

Subscription setup before first charge​

Create the unpaid first order so the customer can review the plan, price, and billing date before money moves. Pay it after they accept. Schedule future renewals only after that first payment succeeds.

Layaway and installment plans​

Keep the layaway plan in your own system and create a separate Inttegro order for each installment. Each payment then has its own amount, idempotency key, and lifecycle while still linking back to the same plan in your data.

Handling edge cases

Customer cancels before payment​

Cancel the Inttegro order as well as updating your own record. This makes the order terminal and prevents a later payment attempt against an order the customer has abandoned. See Cancel an order.

Payment method changes between creation and payment​

The customer can choose a different payment method before payment starts. Pass the newly selected payment-method details when you pay the order; the order does not need to be recreated.

Order expires before payment​

Set an expiration policy for unpaid orders. Look up the order before payment; if it is outside your allowed window, cancel it and ask the customer to create a new one rather than reviving stale prices or inventory decisions.

Testing

Use an application configured for the test environment. Create a draft order, call Pay for an order when your test workflow is ready to charge it, then inspect the returned order. If confirmation is required, follow Confirm a payment with orderId, paymentId, confirmationId, and the test token supplied for that environment.

Key tips

Track order state: Since payment is deferred, maintain clear status tracking in your database. Use your own states—such as pending approval, awaiting inventory, or ready for payment—to record why each order is waiting.

Set expiration policies: Decide how long orders can remain unpaid before they expire. Common policies: 24 hours for standard orders, 7 days for pre-orders, 30 days for B2B approvals. Check age before executing payment.

Communicate clearly: Tell customers when they'll be charged. "You won't be charged until we confirm availability" or "Payment will be collected after manager approval." Set expectations upfront.

Handle abandoned orders: Not all created orders will result in payment. Set up automated processes to follow up on unpaid orders, remind customers, or clean up very old orders from your database.

Next steps

You now know how to decouple order creation from payment execution. This pattern gives you the flexibility to build pre-orders, approval workflows, and any scenario where charging happens after order creation.