Smart operations

THE NEW PAYMENT MODEL

One purchase.
Every attempt.

The operation holds the purchase context. Transactions record what happened each time the customer tried to pay.

A different way to read payments

In Alignet One, a transaction is not necessarily an independent sale. The model has two levels:

Level	What it represents	What you need to know
Operation	The purchase session or intent grouping payment attempts.	Which purchase are we managing, and what is its overall situation?
Transaction	An individual attempt with its own method, identifier, state and history.	What happened to this specific attempt?

One operation can contain several transactions. Each transaction belongs to an operation context. Retrying or changing methods does not, by itself, create another store order.

“Purchase session” describes the business context. Its validity is not necessarily the same as a browser tab, token or local timer. Follow your integration’s validity and retry rules.

The same state names, two different levels

Operations and transactions use the same state names, but describe different resources. Always specify whether a state belongs to the operation or to an attempt. The current states are Registered, Pending, Authorized, Invalid, Declined, Voided, Settled, Expired and Cancelled. Keep the overall operation state separate from each transaction’s state. Abonado (merchant payout) and Devuelto (refunded) are planned but not available yet. Do not make them required conditions in your integration.

Explore one purchase with several attempts

Advance through the example: two attempts are declined and the third is authorized. The operation and store order stay the same; the transaction history grows. The final result is one S/ 50.00 purchase with three attempts, one authorized. Do not add their amounts together and report S/ 150.00 in sales.

What changes in your integration

Keep the store order

Connect the purchase to its operation. Do not create another order just because an attempt was declined.

Keep each attempt's identity

Store every transaction_id and its outcome. Do not overwrite a previous attempt when adding the next.

Show support the journey

Keep the method and response for every attempt and identify the one that was authorized.

Separate reconciliation levels

Count purchases in their operation context and analyze authorizations, declines and adjustments per transaction.

Pending is not declined. After a timeout or while a QR/CIP is pending, query the outcome before encouraging another charge. Do not assume Alignet cancelled other attempts or automatically prevents every duplicate.

Recognize both levels in the API

The transaction query returns an operation structure and a transactions collection.

Field	Level	Purpose
`merchant_operation_number`	Operation	Operation number registered by the merchant. Associate it with your store order.
`operation.state`	Operation	State reported by the platform. Do not automatically replace it with the last attempt’s state.
`operation.transactions[].transaction_id`	Transaction	Attempt identifier for queries and traceability.
`operation.transactions[].state`	Transaction	Current state of this attempt.
`operation.transactions[].lifecycle`	Transaction	State history of this attempt, not a list of the operation’s attempts.

Two different lists: transactions[] groups transactions; lifecycle[] groups events within a transaction. Registered, pending and authorized events do not mean three attempts.

The documented query takes merchant_code, merchant_operation_number and transaction_id. Do not assume a transaction-filtered query necessarily returns the operation’s entire history.

Structure example

Simplified response fragment based on the documented query. Identifiers are illustrative; this is not a request to copy or a complete state catalog.

{
  "operation": {
    "merchant_operation_number": "2391645",
    "state": "AUTORIZADO",
    "amount": "15000",
    "currency": "604",
    "transactions": [
      {
        "transaction_id": "example-tx-01",
        "state": "AUTORIZADO",
        "lifecycle": [
          { "state": "REGISTRADO" },
          { "state": "PENDIENTE" },
          { "state": "AUTORIZADO" }
        ]
      }
    ]
  }
}

This is one operation and one transaction with three events, not three transactions. In this contract, 15000 is an amount in minor units: S/ 150.00 with currency 604 (PEN).

Implementation rules

Connect order and operation. Keep their identifiers separate; do not assume identical formats.
Record each attempt. Store its transaction_id, method, state and support references.
Do not infer payment from the UI. Closing checkout or receiving a callback does not by itself prove approval.
Confirm from your backend. Validate operation, attempt, amount and currency using the appropriate query or notification.
Apply changes idempotently. Repeated notifications or queries must not duplicate fulfillment or register the same sale again.
Preserve history. A subsequent void or refund does not erase the original payment transaction.

Keeping an operation for the same purchase is not the same as blindly resending an HTTP request. Technical retry, expiration and idempotency rules depend on the endpoint and channel.

Check your understanding

Two declines and one authorization: how many purchases?

In the example: one purchase, one operation and three transactions. Only one transaction was authorized.

Three lifecycle events: does that mean three transactions?

No. One transaction changed state three times. All events belong to the same transaction_id.

The last observed transaction was declined. Is the operation lost?

Do not decide from that alone. Check the operation and its attempts. Do not overwrite a confirmed purchase with another attempt’s decline.

Next: transaction states

Learn what each outcome means and how your integration should respond.

Getting started

Integration

Migration

Payments

One purchase.
Every attempt.

A different way to read payments

The same state names, two different levels

Explore one purchase with several attempts

What changes in your integration

Keep the store order

Keep each attempt's identity

Show support the journey

Separate reconciliation levels

Recognize both levels in the API

Structure example

Implementation rules

Check your understanding

Next: transaction states

One purchase.Every attempt.

​A different way to read payments

​The same state names, two different levels

​Explore one purchase with several attempts

​What changes in your integration

Keep the store order

Keep each attempt's identity

Show support the journey

Separate reconciliation levels

​Recognize both levels in the API

​Structure example

​Implementation rules

​Check your understanding

Next: transaction states

One purchase.
Every attempt.

A different way to read payments

The same state names, two different levels

Explore one purchase with several attempts

What changes in your integration

Recognize both levels in the API

Structure example

Implementation rules

Check your understanding