Does Stripe have an Orders API?

Three things called an order

A search for the Stripe Orders API mostly returns products that happen to share the word. Two are current and unrelated to selling your goods; the third is the API this page is about.

Two Orders APIs, both retired

The original: /v1/orders and the order object

Stripe once carried a full commerce layer. The order object held line items and a status that moved as the order was paid and fulfilled, returns were their own object, SKUs described what was for sale, and a SKU's inventory attribute could hold a count Stripe decremented at purchase. In October 2019 Stripe deprecated the API because it could not support Strong Customer Authentication, and support drained out of the SDKs over the releases that followed; the last stripe-node release with the legacy resource was v8.222.0. The reference pages for orders and SKUs no longer resolve. The tutorials and third-party bindings built on them are still indexed, which is why a search for the order object ranks Perl bindings for an API you cannot call.

The replacement: the 2022 Orders beta

In May 2022 Stripe announced a new Orders API in beta: custom checkout flows with line items, with Stripe Tax computing sales tax, VAT, or GST at the API layer. The SDKs shipped it as the replacement for the legacy resource. It never reached general availability. The November 2022 SDK releases removed it, and the stripe-node v11 migration guide records the change in two lines, "Remove Orders resource" and "Remove SKU resource", with nothing else. Today docs.stripe.com/api/orders returns a 404, and stripe.com/docs/orders lands on the Payment Element page, which starts new integrations at Checkout Sessions.

What new integrations use instead

Stripe's documentation starts you at one of two places. The Checkout Sessions API takes line items, renders them at payment time, and hands back a paid session. The PaymentIntents API is lower level: an amount and a currency. Either way the durable record is payment-shaped. The fulfillment guide's own instruction is to retrieve the session with line items expanded and save a copy of the payment details and line items in your own database, and a refund afterward is an amount against the payment, not a change to line items.

The order layer, since then

The need the order object served did not retire with it. Teams on Stripe build the layer themselves: an orders table, totals computed in application code, refund math, and a webhook state machine keeping it all synchronized. What that takes to run correctly is its own subject: Stripe as your source of truth covers the architecture and its drift traps, the inventory reference the stock half, and the refund reference the money half.

Orders on Flint

Flint is that order layer run as a product on Stripe rails. The order is the first call, not a table you maintain:

curl -X POST https://api.withflintpay.com/v1/orders \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Idempotency-Key: order-tote-001" \
  -d '{
    "line_items": [
      { "name": "Canvas tote bag", "quantity": 1,
        "unit_price_money": { "amount": 2500, "currency": "USD" } },
      { "name": "Enamel pin", "quantity": 2,
        "unit_price_money": { "amount": 800, "currency": "USD" } }
    ]
  }'

{
  "data": {
    "order_id": "ord_1kmn0aExample",
    "status": "open",
    "payment_status": "unpaid",
    "pricing_amounts": {
      "subtotal_money": { "amount": 4100, "currency": "USD" },
      "tax_money":      { "amount": 328,  "currency": "USD" },
      "total_money":    { "amount": 4428, "currency": "USD" }
    },
    "settlement_amounts": {
      "paid_money":        { "amount": 0,    "currency": "USD" },
      "outstanding_money": { "amount": 4428, "currency": "USD" }
    }
  }
}

Totals come back computed: pricing_amounts is what should be collected, settlement_amounts what actually happened. Payments derive their amount from the order balance rather than from a number your code submits, webhooks report order state, and a refund targets line items while the API computes the money, including each line's share of tax:

curl -X POST https://api.withflintpay.com/v1/refunds \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Idempotency-Key: refund-ord-003" \
  -d '{
    "order_id": "ord_1kmn0aExample",
    "reason": "defective_product",
    "line_items": [
      { "order_line_item_id": "li_1kmn0aExample", "quantity": 1 }
    ]
  }'

One thing this is not: a plugin for your existing Stripe account. Flint provisions and operates its own Stripe-based processing, so there is no way to connect a Stripe account you already have, and Flint inherits Stripe underwriting. If Stripe declined your business, Flint cannot approve it.

The Orders API reference has every field on the requests above, Why Flint is orders-first is the concept in full, and order activities covers the timeline every order keeps.

Questions, answered

Sources

• stripe-node migration guide for v9: the legacy Orders API deprecation (October 2019)
• stripe-node migration guide for v11 (2022-11-15): Orders and SKU resources removed
• stripe-python migration guide for v3: the new Orders API replacing the legacy API
• Stripe's Orders API beta announcement (May 2022)
• Stripe docs: Payment Element, the page stripe.com/docs/orders serves today
• Stripe docs: Fulfill orders after checkout
• Stripe API reference: Climate orders
• Stripe API reference: Terminal hardware orders

Related

• Stripe as your source of truth: the architecture question underneath this one; where the record of the sale should live.
• Does Stripe track inventory?: the stock half of what the Orders API used to carry.
• How to refund a line item in Stripe: the refund half, with the proration and rounding traps.
• Why Flint is orders-first: the order as the durable record, from creation through settlement.