From 3a142e964badf7cd5a77da7d866a646608cdfa1c Mon Sep 17 00:00:00 2001 From: Suliman Awad Date: Wed, 3 Jun 2026 12:14:31 +0300 Subject: [PATCH 1/3] docs(auto-debit): restructure Recurring Payments page and add One-Step Checkout Reworks the Recurring Payments & Auto-Debit guide so it reads overview-first and makes One-Step Checkout a first-class option for merchant-initiated charges, aligning the page with the Native Payments API. Content: - Restructure to a clean section flow: Introduction -> When to Use (why/when) -> Setup (Quick Start/Authentication pointer + prerequisites) -> Guide. Keep onboarding/tooling pointers out of the overview. - Document One-Step Checkout for the MIT: once a CIT exists, the merchant can create the session and charge the saved token in a single Checkout API call via payment_instrument, instead of the two-step Checkout + Auto-Debit flow. - Add a two-step vs one-step MIT flowchart (new OneStepMITFlow inline, theme-aware SVG diagram). - State explicitly that the API enforces CIT-before-MIT (a successful CIT must exist or the charge fails with a validation error). - Add a note that an auto-debit transaction must use exactly one pg_code (one gateway) for the lifetime of the agreement. - Add a pre-flight checklist before the Auto-Debit call and two FAQ entries (MIT-without-CIT, different gateways per CIT/MIT). - Link One-Step Checkout to the Checkout API one-step section at every mention; move the Boost Your Integration tip to the start of Step-by-Step. API alignment: - Use the canonical /b/pbl/v2/payment/auto-debit/ endpoint and embed auto-debit-2.api.mdx, matching the Native Payments page (both paths are live in the spec with identical schemas). - Fix two broken relative links on the page (now absolute) and restore JSON indentation in the First Payment (CIT) examples. Also fixes a missing space in the Checkout API One-Step Checkout intro. --- .../cards-and-tokens/recurring-payments.mdx | 63 ++++++--- docs/developers/payments/checkout-api.mdx | 2 +- src/diagrams/OneStepMITFlow.tsx | 121 ++++++++++++++++++ 3 files changed, 169 insertions(+), 17 deletions(-) create mode 100644 src/diagrams/OneStepMITFlow.tsx diff --git a/docs/developers/cards-and-tokens/recurring-payments.mdx b/docs/developers/cards-and-tokens/recurring-payments.mdx index 9ab5b4d..66fe918 100644 --- a/docs/developers/cards-and-tokens/recurring-payments.mdx +++ b/docs/developers/cards-and-tokens/recurring-payments.mdx @@ -10,15 +10,12 @@ import TestCardCallout from "@site/src/components/TestCardCallout"; import FAQ, { FAQItem } from "@site/src/components/FAQ"; import StepGuide from "@site/src/components/StepGuide"; import RecurringFlow from "@site/src/diagrams/RecurringFlow"; +import OneStepMITFlow from "@site/src/diagrams/OneStepMITFlow"; # Recurring Payments & Auto-Debit Auto-debit is a financial arrangement where a customer authorizes a merchant to automatically deduct money from their saved card. This covers subscriptions, installments, recurring billing, and event-based charges — all processed without the customer needing to be present after the initial setup. -:::tip[Boost Your Integration] -Ottu offers SDKs and tools to speed up your integration. See [Getting Started](/developers/getting-started/#boost-your-integration) for all available options. -::: - ## When to Use - **Subscriptions** — monthly or annual recurring charges for SaaS, memberships, or content @@ -28,14 +25,20 @@ Ottu offers SDKs and tools to speed up your integration. See [Getting Started](/ ## Setup +New to Ottu? Run through the [Quick Start](/developers/getting-started/) to make your first API call and to set up [Authentication](/developers/getting-started/authentication/) — every auto-debit charge is a server-to-server request signed with your [private API key](/developers/getting-started/authentication/#api-key-auth). + Before implementing auto-debit, ensure you have: -- A [Payment Gateway](/developers/payments/payment-methods/) with auto-debit capability enabled +- A [Payment Gateway](/developers/payments/payment-methods/) (MID) with auto-debit enabled — only **one** gateway can be used per auto-debit transaction (see the note below) - The [Checkout API](/developers/payments/checkout-api/) for creating payment sessions - [Tokenization](/developers/cards-and-tokens/tokenization/) set up — cards must be tokenized before they can be auto-debited - A [webhook endpoint](/developers/webhooks/) configured to receive payment notifications - Familiarity with the [User Cards API](/developers/cards-and-tokens/user-cards/) for card management +:::note[One pg_code per auto-debit transaction] +An auto-debit transaction must route through a **single** gateway. Always pass exactly **one** [`pg_code`](/developers/payments/payment-methods/) — for an MID that has auto-debit enabled — when you create the CIT session and on every subsequent MIT charge. Use the **same** `pg_code` for the whole lifetime of the agreement. +::: + ## Guide ### Key Concepts @@ -45,6 +48,10 @@ Auto-debit payments involve two types of transactions: - **CIT (Cardholder Initiated Transaction)** — The first payment where the customer is present, enters their card details, and authorizes future charges. This establishes the agreement and saves the card token. - **MIT (Merchant Initiated Transaction)** — Subsequent automatic charges triggered by the merchant using the saved token. The customer is not present during these transactions. +:::warning[A successful CIT is required before any MIT] +Ottu **enforces** the CIT-before-MIT order. The Auto-Debit API validates that a **successful CIT exists** for the customer/agreement before it allows a merchant-initiated charge. Attempting an MIT against a token that never completed a customer-present CIT is rejected with a **validation error**. +::: + #### Agreement An agreement is a commercial contract between you and your customer that authorizes you to store and use their payment details for subsequent transactions. Each agreement has: @@ -73,8 +80,8 @@ Only **one card** can be linked to an agreement at any time. To change the card, 1. **CIT** — Merchant creates a session with `payment_type: auto_debit` and an `agreement` object. 2. **Payment** — Customer enters their card via the Checkout SDK or hosted page and completes 3DS authentication. 3. **Webhook** — Ottu delivers the token. Save `token.token` and `token.pg_code` for future charges. -4. **MIT** — Merchant charges the token by creating a new session, then calling the Native Payments API (or using [One-Step Checkout](/developers/payments/checkout-api#one-step-checkout)). -5. **Result** — The Native Payments API (or One-Step Checkout) returns the payment result **directly in the API response** — there is no webhook for MIT charges. No customer interaction needed. +4. **MIT** — Merchant charges the token by creating a new session, then calling the [Auto-Debit (Native Payments) API](/developers/payments/native-payments/) (or using [One-Step Checkout](/developers/payments/checkout-api#one-step-checkout) for a single call). +5. **Result** — The Auto-Debit API (or One-Step Checkout) returns the payment result **directly in the API response** — there is no webhook for MIT charges. No customer interaction needed. ### Live Demo @@ -86,6 +93,10 @@ Experience the complete recurring payment lifecycle. Save a test card, watch the ### Step-by-Step +:::tip[Boost Your Integration] +Ottu offers SDKs and tools to speed up your integration. See [Getting Started](/developers/getting-started/#boost-your-integration) for all available options. +::: + #### First Payment (CIT) Collect the customer's card using one of these options:

• Checkout SDK (recommended) — initialize with the session_id
• Redirect to checkout_url — sends the customer to Ottu's hosted checkout page
• Redirect to payment_methods.redirect_url — sends the customer directly to a specific gateway's card entry page, + description: <>Collect the customer's card using one of these options:

• Checkout SDK (recommended) — initialize with the session_id
• Redirect to checkout_url — sends the customer to Ottu's hosted checkout page
• Redirect to payment_methods.redirect_url — sends the customer directly to a specific gateway's card entry page, }, { title: "Receive Webhook with Token", - description: <>After the customer completes the payment, Ottu sends a webhook notification with the token:

{`{
+    description: <>After the customer completes the payment, Ottu sends a webhook notification with the token:

{`{
   "session_id": "4a462681df6aab64e27cedc9bbf733cd6442578b",
   "result": "success",
   "state": "paid",
@@ -159,14 +170,24 @@ Experience the complete recurring payment lifecycle. Save a test card, watch the
 
 #### Subsequent Payments (MIT)
 
-Once you have the token, you can charge the customer automatically using either of the following approaches.
+Once you have the token, you can charge the customer automatically — no customer interaction required.
+
+**Before calling the Auto-Debit API, ensure:**
+
+- ✅ A successful [CIT](#key-concepts) exists for this customer/agreement
+- ✅ You have the `token` from the first payment
+- ✅ You're using a `pg_code` for an MID that has auto-debit enabled
 
-**Two-Step (Checkout API + Native Payments API):**
+There are two ways to charge the saved token. The **two-step** flow creates a session and then charges it; [**One-Step Checkout**](/developers/payments/checkout-api#one-step-checkout) collapses both into a single call by passing the token in `payment_instrument`:
+
+
+
+##### Two-Step (Checkout API + Auto-Debit API)
 
 1. Create a new session via the [Checkout API](/developers/payments/checkout-api/) with the same `pg_code`, `agreement.id`, and `customer_id`
-2. Call the Native Payments API with the `session_id` and `token`:
+2. Call the [Auto-Debit (Native Payments) API](/developers/payments/native-payments/) with the `session_id` and `token`:
 
-```json title="POST /b/pbl/v2/auto-debit/ — Charge Saved Card"
+```json title="POST /b/pbl/v2/payment/auto-debit/ — Charge Saved Card"
 {
   "session_id": "19aa7cd3cfc43d9d7641f6c433767b25cbcd6c18",
   "token": "9923965822244314"
@@ -177,9 +198,9 @@ Once you have the token, you can charge the customer automatically using either
 Use the **same** `pg_code`, `agreement.id`, and `customer_id` as the first payment. The amount may vary if the agreement's `amount_variability` is set to `"variable"`.
 :::
 
-**One-Step (Checkout API with `payment_instrument`):**
+##### [One-Step](/developers/payments/checkout-api#one-step-checkout) (Checkout API with `payment_instrument`) — Recommended
 
-Combine session creation and payment in a single call using [`payment_instrument`](/developers/payments/checkout-api#one-step-checkout). To see this in action, try the [Live Demo](#live-demo) above.
+Skip the separate charge call entirely. Pass the saved token in [`payment_instrument`](/developers/payments/checkout-api#one-step-checkout) and the [Checkout API](/developers/payments/checkout-api/) creates the session **and** charges the token in a single request, returning the payment result directly in the response. To see this in action, try the [Live Demo](#live-demo) above.
 
 ```json title="POST /b/checkout/v1/pymt-txn/ — One-Step Checkout"
 {
@@ -247,7 +268,7 @@ For recurring billing, notify customers before each charge:
 
 ## API Reference
 
-
+
 
 ## Best Practices
 
@@ -301,6 +322,16 @@ For recurring billing, notify customers before each charge:
     SDK simplifies UI implementation and is required for certain payment methods
     like Apple Pay and Google Pay.
   
+  
+    The Auto-Debit API rejects it with a validation error. A successful,
+    customer-present [CIT](#key-concepts) must exist for the customer/agreement
+    before any merchant-initiated charge is allowed.
+  
+  
+    No. An auto-debit agreement is tied to a single gateway — use the **same**
+    [`pg_code`](/developers/payments/payment-methods/) (for an MID with
+    auto-debit enabled) on the CIT and on every MIT charge.
+  
 
 
 ## What's Next?
diff --git a/docs/developers/payments/checkout-api.mdx b/docs/developers/payments/checkout-api.mdx
index 89dee03..d93c390 100644
--- a/docs/developers/payments/checkout-api.mdx
+++ b/docs/developers/payments/checkout-api.mdx
@@ -304,7 +304,7 @@ Merchants can use the [Checkout API](/developers/payments/checkout-api) to creat
 
 ## One-Step Checkout
 
-One-Step Checkout combines the [Checkout API](/developers/payments/checkout-api/) and the [Native Payments](/developers/payments/native-payments/)into a single backend request.\
+One-Step Checkout combines the [Checkout API](/developers/payments/checkout-api/) and the [Native Payments](/developers/payments/native-payments/) into a single backend request.\
 Instead of creating a session first and then calling a separate payment endpoint, you can perform both actions in one step by including the [payment_instrument](/developers/payments/checkout-api/) parameter.
 
 This flow is ideal when you want to immediately process a payment as it's created, for example:
diff --git a/src/diagrams/OneStepMITFlow.tsx b/src/diagrams/OneStepMITFlow.tsx
new file mode 100644
index 0000000..ccda735
--- /dev/null
+++ b/src/diagrams/OneStepMITFlow.tsx
@@ -0,0 +1,121 @@
+import React from "react";
+import Diagram from "@site/src/components/Diagram";
+
+/**
+ * Auto-debit MIT charge: two-step vs One-Step Checkout.
+ *
+ * Single inline, theme-aware SVG generated by the `svg-diagram` skill
+ * (scripts/inline-svg.py, slug "auto-debit-one-step"). Scoped `
+  
+
+  
+  TWO-STEP · TWO API CALLS
+
+  
+  Merchant Backend
+  Your server
+
+  
+  Checkout API
+  Create session
+
+  
+  Auto-Debit API
+  Charge saved token
+
+  
+  Payment result
+  state = paid
+
+  
+  
+  1 · create session
+
+  
+  
+  2 · charge token
+
+  
+  
+  result
+
+  
+  ONE-STEP · ONE API CALL
+
+  
+  Merchant Backend
+  Your server
+
+  
+  Checkout API
+  token in payment_instrument
+
+  
+  Payment result
+  state = paid
+
+  
+  
+  single call
+
+  
+  
+  direct result
+`;
+
+export default function OneStepMITFlow(): React.JSX.Element {
+  return (
+    
+  );
+}

From ecaf268773964ddc384f019a0c12daa467926434 Mon Sep 17 00:00:00 2001
From: Suliman Awad 
Date: Thu, 11 Jun 2026 10:23:07 +0300
Subject: [PATCH 2/3] change (auto-debit api) to (nativr payments api).

---
 .../cards-and-tokens/recurring-payments.mdx   | 100 +++++++++---------
 1 file changed, 50 insertions(+), 50 deletions(-)

diff --git a/docs/developers/cards-and-tokens/recurring-payments.mdx b/docs/developers/cards-and-tokens/recurring-payments.mdx
index 66fe918..5199c9d 100644
--- a/docs/developers/cards-and-tokens/recurring-payments.mdx
+++ b/docs/developers/cards-and-tokens/recurring-payments.mdx
@@ -49,7 +49,7 @@ Auto-debit payments involve two types of transactions:
 - **MIT (Merchant Initiated Transaction)** — Subsequent automatic charges triggered by the merchant using the saved token. The customer is not present during these transactions.
 
 :::warning[A successful CIT is required before any MIT]
-Ottu **enforces** the CIT-before-MIT order. The Auto-Debit API validates that a **successful CIT exists** for the customer/agreement before it allows a merchant-initiated charge. Attempting an MIT against a token that never completed a customer-present CIT is rejected with a **validation error**.
+Ottu **enforces** the CIT-before-MIT order. The Native Payments API validates that a **successful CIT exists** for the customer/agreement before it allows a merchant-initiated charge. Attempting an MIT against a token that never completed a customer-present CIT is rejected with a **validation error**.
 :::
 
 #### Agreement
@@ -80,8 +80,8 @@ Only **one card** can be linked to an agreement at any time. To change the card,
 1. **CIT** — Merchant creates a session with `payment_type: auto_debit` and an `agreement` object.
 2. **Payment** — Customer enters their card via the Checkout SDK or hosted page and completes 3DS authentication.
 3. **Webhook** — Ottu delivers the token. Save `token.token` and `token.pg_code` for future charges.
-4. **MIT** — Merchant charges the token by creating a new session, then calling the [Auto-Debit (Native Payments) API](/developers/payments/native-payments/) (or using [One-Step Checkout](/developers/payments/checkout-api#one-step-checkout) for a single call).
-5. **Result** — The Auto-Debit API (or One-Step Checkout) returns the payment result **directly in the API response** — there is no webhook for MIT charges. No customer interaction needed.
+4. **MIT** — Merchant charges the token by creating a new session, then calling the [Native Payments API](/developers/payments/native-payments/) (or using [One-Step Checkout](/developers/payments/checkout-api#one-step-checkout) for a single call).
+5. **Result** — The Native Payments API (or One-Step Checkout) returns the payment result **directly in the API response** — there is no webhook for MIT charges. No customer interaction needed.
 
 ### Live Demo
 
@@ -105,10 +105,10 @@ Ottu offers SDKs and tools to speed up your integration. See [Getting Started](/
     description: <>Before creating a session, call the Payment Methods API with auto_debit: true to discover which gateways support tokenization and auto-debit.

{`POST /b/pbl/v2/payment-methods/
 
 {
-  "plugin": "payment_request",
-  "operation": "purchase",
-  "currencies": ["KWD"],
-  "auto_debit": true
+"plugin": "payment_request",
+"operation": "purchase",
+"currencies": ["KWD"],
+"auto_debit": true
 }`}
 Use the returned pg_codes in the next step.,
   },
   {
@@ -116,28 +116,28 @@ Ottu offers SDKs and tools to speed up your integration. See [Getting Started](/
     description: <>Create a session with payment_type: auto_debit and the agreement object. Use a unique customer_id per customer — all future MIT charges and saved cards are associated with this ID.

{`POST /b/checkout/v1/pymt-txn/
 
 {
-  "type": "e_commerce",
-  "amount": "200.00",
-  "payment_type": "auto_debit",
-  "currency_code": "KWD",
-  "pg_codes": ["credit-card"],
-  "customer_id": "cust_123",
-  "webhook_url": "https://yourwebsite.com/webhook",
-  "agreement": {
-    "id": "A123456789",
-    "type": "recurring",
-    "amount_variability": "fixed",
-    "start_date": "01/04/2026",
-    "expiry_date": "01/04/2027",
-    "cycle_interval_days": 30,
-    "total_cycles": 12,
-    "frequency": "monthly",
-    "seller": {
-      "name": "Your-Business-Name",
-      "short_name": "YBN",
-      "category_code": "1234"
-    }
-  }
+"type": "e_commerce",
+"amount": "200.00",
+"payment_type": "auto_debit",
+"currency_code": "KWD",
+"pg_codes": ["credit-card"],
+"customer_id": "cust_123",
+"webhook_url": "https://yourwebsite.com/webhook",
+"agreement": {
+"id": "A123456789",
+"type": "recurring",
+"amount_variability": "fixed",
+"start_date": "01/04/2026",
+"expiry_date": "01/04/2027",
+"cycle_interval_days": 30,
+"total_cycles": 12,
+"frequency": "monthly",
+"seller": {
+"name": "Your-Business-Name",
+"short_name": "YBN",
+"category_code": "1234"
+}
+}
 }`}
,
   },
   {
@@ -147,23 +147,23 @@ Ottu offers SDKs and tools to speed up your integration. See [Getting Started](/
   {
     title: "Receive Webhook with Token",
     description: <>After the customer completes the payment, Ottu sends a webhook notification with the token:

{`{
-  "session_id": "4a462681df6aab64e27cedc9bbf733cd6442578b",
-  "result": "success",
-  "state": "paid",
-  "payment_type": "auto_debit",
-  "customer_id": "cust_123",
-  "agreement": {
-    "id": "A123456789",
-    "type": "recurring"
-  },
-  "token": {
-    "token": "9923965822244314",
-    "customer_id": "cust_123",
-    "brand": "VISA",
-    "number": "\*\*\*\* 1019",
-    "pg_code": "credit-card",
-    "agreements": ["A123456789"]
-  }
+"session_id": "4a462681df6aab64e27cedc9bbf733cd6442578b",
+"result": "success",
+"state": "paid",
+"payment_type": "auto_debit",
+"customer_id": "cust_123",
+"agreement": {
+"id": "A123456789",
+"type": "recurring"
+},
+"token": {
+"token": "9923965822244314",
+"customer_id": "cust_123",
+"brand": "VISA",
+"number": "\*\*\*\* 1019",
+"pg_code": "credit-card",
+"agreements": ["A123456789"]
+}
 }`}
Save the token.token and token.pg_code — you'll need them for subsequent charges.,
 },
 ]} nextSectionId="subsequent-payments-mit" />
@@ -172,7 +172,7 @@ Ottu offers SDKs and tools to speed up your integration. See [Getting Started](/
 
 Once you have the token, you can charge the customer automatically — no customer interaction required.
 
-**Before calling the Auto-Debit API, ensure:**
+**Before calling the Native Payments API, ensure:**
 
 - ✅ A successful [CIT](#key-concepts) exists for this customer/agreement
 - ✅ You have the `token` from the first payment
@@ -182,10 +182,10 @@ There are two ways to charge the saved token. The **two-step** flow creates a se
 
 
 
-##### Two-Step (Checkout API + Auto-Debit API)
+##### Two-Step (Checkout API + Native Payments API)
 
 1. Create a new session via the [Checkout API](/developers/payments/checkout-api/) with the same `pg_code`, `agreement.id`, and `customer_id`
-2. Call the [Auto-Debit (Native Payments) API](/developers/payments/native-payments/) with the `session_id` and `token`:
+2. Call the [Native Payments API](/developers/payments/native-payments/) with the `session_id` and `token`:
 
 ```json title="POST /b/pbl/v2/payment/auto-debit/ — Charge Saved Card"
 {
@@ -323,7 +323,7 @@ For recurring billing, notify customers before each charge:
     like Apple Pay and Google Pay.
   
   
-    The Auto-Debit API rejects it with a validation error. A successful,
+    The Native Payments API rejects it with a validation error. A successful,
     customer-present [CIT](#key-concepts) must exist for the customer/agreement
     before any merchant-initiated charge is allowed.
   

From 2262af911ca059866ba080d7de62652abdeeb7a8 Mon Sep 17 00:00:00 2001
From: Suliman Awad 
Date: Thu, 11 Jun 2026 11:03:49 +0300
Subject: [PATCH 3/3] docs(auto-debit): apply tech lead PR review notes on
 Recurring Payments
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Apply the review feedback from the tech lead on the Recurring Payments
& Auto-Debit page:

- Soften the CIT-before-MIT callout — change it from a warning to an
  informational note and reword it to state the requirement plainly,
  dropping the 'Ottu enforces / validation error' framing.
- Reword the 'one pg_code per auto-debit' note to plainer phrasing and
  refer to it as a payment rather than a transaction.
- Simplify the MIT section: remove the pre-flight checklist and the
  two-step vs one-step flowchart, leaving a short lead-in to the two
  charge approaches.
- Remove the now-unused OneStepMITFlow diagram component.
---
 .../cards-and-tokens/recurring-payments.mdx   |  21 +--
 src/diagrams/OneStepMITFlow.tsx               | 121 ------------------
 2 files changed, 5 insertions(+), 137 deletions(-)
 delete mode 100644 src/diagrams/OneStepMITFlow.tsx

diff --git a/docs/developers/cards-and-tokens/recurring-payments.mdx b/docs/developers/cards-and-tokens/recurring-payments.mdx
index 5199c9d..6207219 100644
--- a/docs/developers/cards-and-tokens/recurring-payments.mdx
+++ b/docs/developers/cards-and-tokens/recurring-payments.mdx
@@ -10,7 +10,6 @@ import TestCardCallout from "@site/src/components/TestCardCallout";
 import FAQ, { FAQItem } from "@site/src/components/FAQ";
 import StepGuide from "@site/src/components/StepGuide";
 import RecurringFlow from "@site/src/diagrams/RecurringFlow";
-import OneStepMITFlow from "@site/src/diagrams/OneStepMITFlow";
 
 # Recurring Payments & Auto-Debit
 
@@ -35,8 +34,8 @@ Before implementing auto-debit, ensure you have:
 - A [webhook endpoint](/developers/webhooks/) configured to receive payment notifications
 - Familiarity with the [User Cards API](/developers/cards-and-tokens/user-cards/) for card management
 
-:::note[One pg_code per auto-debit transaction]
-An auto-debit transaction must route through a **single** gateway. Always pass exactly **one** [`pg_code`](/developers/payments/payment-methods/) — for an MID that has auto-debit enabled — when you create the CIT session and on every subsequent MIT charge. Use the **same** `pg_code` for the whole lifetime of the agreement.
+:::note[One `pg_code` per auto-debit payment]
+An auto-debit payment must route through a single gateway. Always pass exactly one [`pg_code`](/developers/payments/payment-methods/) — for an MID that has auto-debit enabled — when you create the CIT session and on every subsequent MIT charge. Use the same `pg_code` for the whole lifetime of the agreement.
 :::
 
 ## Guide
@@ -48,8 +47,8 @@ Auto-debit payments involve two types of transactions:
 - **CIT (Cardholder Initiated Transaction)** — The first payment where the customer is present, enters their card details, and authorizes future charges. This establishes the agreement and saves the card token.
 - **MIT (Merchant Initiated Transaction)** — Subsequent automatic charges triggered by the merchant using the saved token. The customer is not present during these transactions.
 
-:::warning[A successful CIT is required before any MIT]
-Ottu **enforces** the CIT-before-MIT order. The Native Payments API validates that a **successful CIT exists** for the customer/agreement before it allows a merchant-initiated charge. Attempting an MIT against a token that never completed a customer-present CIT is rejected with a **validation error**.
+:::note[A successful CIT is required before any MIT]
+A CIT must complete successfully before you can run an MIT. The Native Payments API checks for a successful CIT on the customer's agreement, so a token that never completed a customer-present CIT can't be charged.
 :::
 
 #### Agreement
@@ -170,17 +169,7 @@ Ottu offers SDKs and tools to speed up your integration. See [Getting Started](/
 
 #### Subsequent Payments (MIT)
 
-Once you have the token, you can charge the customer automatically — no customer interaction required.
-
-**Before calling the Native Payments API, ensure:**
-
-- ✅ A successful [CIT](#key-concepts) exists for this customer/agreement
-- ✅ You have the `token` from the first payment
-- ✅ You're using a `pg_code` for an MID that has auto-debit enabled
-
-There are two ways to charge the saved token. The **two-step** flow creates a session and then charges it; [**One-Step Checkout**](/developers/payments/checkout-api#one-step-checkout) collapses both into a single call by passing the token in `payment_instrument`:
-
-
+Once you have the token, you can charge the customer automatically using either of the following approaches.
 
 ##### Two-Step (Checkout API + Native Payments API)
 
diff --git a/src/diagrams/OneStepMITFlow.tsx b/src/diagrams/OneStepMITFlow.tsx
deleted file mode 100644
index ccda735..0000000
--- a/src/diagrams/OneStepMITFlow.tsx
+++ /dev/null
@@ -1,121 +0,0 @@
-import React from "react";
-import Diagram from "@site/src/components/Diagram";
-
-/**
- * Auto-debit MIT charge: two-step vs One-Step Checkout.
- *
- * Single inline, theme-aware SVG generated by the `svg-diagram` skill
- * (scripts/inline-svg.py, slug "auto-debit-one-step"). Scoped `
-  
-
-  
-  TWO-STEP · TWO API CALLS
-
-  
-  Merchant Backend
-  Your server
-
-  
-  Checkout API
-  Create session
-
-  
-  Auto-Debit API
-  Charge saved token
-
-  
-  Payment result
-  state = paid
-
-  
-  
-  1 · create session
-
-  
-  
-  2 · charge token
-
-  
-  
-  result
-
-  
-  ONE-STEP · ONE API CALL
-
-  
-  Merchant Backend
-  Your server
-
-  
-  Checkout API
-  token in payment_instrument
-
-  
-  Payment result
-  state = paid
-
-  
-  
-  single call
-
-  
-  
-  direct result
-`;
-
-export default function OneStepMITFlow(): React.JSX.Element {
-  return (
-    
-  );
-}