One-Step Checkout

One-Step Checkout combines the Checkout API and the Native Payment API 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 parameter.

This flow is ideal when you want to immediately process a payment as it’s created, for example:

• A “Buy Now” button on a product page that charges the customer right away.

• A subsequent auto-debit payment using a stored token.

• A wallet-based purchase (Apple Pay / Google Pay) where you already have the payment payload on the server and don’t use Checkout SDK.

• Instant, server-triggered payments that must both create and execute the payment in real time.

By using payment_instrument, Ottu automatically creates the session, validates the configuration, and processes the payment through the selected gateway — returning a unified response that includes both the session and transaction details.

When to Use

Use One-Step Checkout when you:

• Want to create and process a payment in a single backend call.

• Need to handle instant payment actions (like “Buy Now”) directly from your backend.

• Are performing a recurring or auto-debit payment using a stored token.

• Already have the payment credentials (wallet payload or token) and don’t need the SDK-based collection flow.

Supported Instruments

instrument_type	Description	Typical Use Case
apple_pay	Apple Pay digital wallet	Apple Pay supported devices
google_pay	Google Pay digital wallet	Google Pay from Android or Chrome
token	Token-based stored or recurring payment	Auto-debit or saved card tokenized payments

Rules & Restrictions

• Only one pg_codes is allowed per request.

• The selected gateway must support the chosen instrument_type.

• The payload must match exactly the format received from the provider — no alterations should be made.

• The API must be called server-to-server, never from the client.

How it Works

When your backend is ready to initiate a direct payment using a wallet or card token (e.g., Apple Pay), it should call the Checkout API and include the payment_instrument parameter. This parameter tells Ottu to both create and attempt to pay the transaction in a single call, using the payment data you provide. The example below shows how this works for Apple Pay, but the same structure applies to other instruments (e.g., Google Pay) with their own payload formats.

Server-to-server only

The payment_instrument parameter must only be used in server-to-server integrations. Never call this API directly from the client side, as it may expose sensitive credentials or payment data.

Request Example: Apple Pay

curl--location 'https://sandbox.ottu.net/b/checkout/v1/pymt-txn/'\
  --header 'Authorization: Api-Key GYj5Na8H.29g9hqNjm11nORQMa2WiZwIBQQ49MdAL'\
  --header 'Content-Type: application/json'\
  --data - raw '{
"type": "e_commerce",
"pg_codes": [
  "knet-apple"
],
"amount": "1",
"currency_code": "KWD",
"payment_instrument": {
  "instrument_type": "apple_pay",
  "payload": {
    "paymentData": {
      "data": "b1lwXgprLF8Ca/HeVwjVq3qHovPdwJ8M8IAYxG...",
      "signature": "MIAGCSqGSIb3DQEHA...",
      "header": {
        "publicKeyHash": "aqFxqE8fnxrAP7...",
        "ephemeralPublicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0D..."
      },
      "version": "EC_v1"
    },
    "paymentMethod": {
      "displayName": "Visa 5766",
      "network": "Visa",
      "type": "debit"
    },
    "transactionIdentifier": "7134E7D22988391FA183A61A191AE14CD0..."
  }
}
}
'

In this example, Ottu receives an Apple Pay token in payment_instrument.payload and uses it to authorize and capture the payment with the selected gateway.

Response Behavior When payment_instrument Is Used

When a valid payment_instrument is provided, Ottu creates the transaction and attempts to complete the payment immediately in the same Checkout API call. Instead of returning the standard Checkout API response (used for redirect/hosted flows), the API returns a transaction result payload that follows the same structure as the payment notification (webhook) data. Your backend can process this response directly as the final payment result (e.g., mark the order as paid when state = "paid").

Response Example

{
  "result": "success",
  "session_id": "dc762e8e9dc937c84de01a79fdb74439b6081546",
  "state": "paid",
  "signature": "7134E7D22988391FA183A61A191AE14CD0",
  ...
}

FAQ

1. When should One-Step Checkout be used?

Use One-Step Checkout when you want to create and execute a payment immediately, such as:

• “Buy Now” actions that must charge instantly.

• Auto-debit or recurring payments using a stored token.

• Wallet-based payments (Apple Pay / Google Pay) when the payment payload is already available on the server.

• Server-triggered payments requiring real-time authorization and capture.

2. What rules or restrictions apply?

• Only one pg_codes value is allowed per request.

• The selected gateway must support the chosen instrument_type.

• The payload must match the provider’s format exactly—no modifications.

• Must be executed server-to-server using Private API keys.

3. What are the benefits of One-Step Checkout?

• Single backend call → lower latency and simpler logic.

• Consistent structure with the Native Payment API.

• Unified handling of session creation + payment execution.

• Ideal for wallets and tokenized recurring payments.

4. What does the response look like?

The API returns a unified response that includes:

• Payment result

• Session details

• Transaction status

Additionally, the webhook payload follows the same structure as Ottu’s Payment Webhook Notification parameters. Expected fields can be reviewed here.