Skip to main content
A terminal session is a regular Checkout session with three additions:
  1. A payment profile that enables the seitatech.in_person payment method.
  2. The order.store identifiers that route the payment to a specific terminal.
  3. A publish configuration that auto-initiates the payment on the terminal.
The sections below cover each piece in order, then bring them together in a full request.

​
Endpoint

POST https://checkout.dintero.com/v1/sessions-profile
Authorization: Bearer <token>
Content-Type: application/json
See POST /sessions-profile for the full schema.

​
1. Enable the payment method (payment profile)

In-person payments are enabled on a payment profile in Dintero Backoffice → Settings → Payment Profiles. Enable Seitatech In-person on the profile you reference with profile_id, and the session accepts terminal payments without any payment-method configuration in the request body.
Managing payment methods through profiles means you can add or change methods without redeploying integration code. Avoid sending a hardcoded configuration.seitatech block on the request - let the profile drive the payment method.

​
2. Route to a terminal (order.store identifiers)

The payment profile toggles the payment method on; order.store says which physical terminal the payment runs on. The terminal ID belongs in order.store.terminal_id. 
{
  "order": {
    "store": {
      "id": "oslo-center",
      "terminal_id": "T0292",
      "payout_destination_id": "seller-1"
    }
  }
}
The three fields are required together for in-person payments:
FieldDescription
order.store.idYour merchant store identifier - the store_id you sent when creating the store, the same one you already use in the payment-link flow. Not the Dintero-generated id.
order.store.terminal_idThe terminal_id returned when the terminal was registered (for example P11223351-T0013). Must be enrolled and linked to the store.
order.store.payout_destination_idThe payout_destination_id linked to the store.
The order.store.id you use today in the payment-link flow is fine to keep using - in-person payments use the same store identifier. You just need to add terminal_id and payout_destination_id alongside it.

​
3. Auto-initiate the payment on the terminal (publish)

Add a publish push/terminal configuration to the session request to auto-initiate the payment on the terminal as soon as the session is created. 
{
  "configuration": {
    "publish": [
      {
        "channel": "push",
        "type": "terminal"
      }
    ]
  }
}
This works whether seitatech.in_person is the only enabled payment method or there are other payment methods on the payment profile. The publish configuration auto-initiates the payment on the terminal in both cases.

​
Sale: full request

This example combines all three pieces to create a session that immediately triggers a payment on terminal T0292 at store oslo-center for 399.00 NOK. The payment profile referenced by profile_id has Seitatech In-person enabled, and the publish configuration auto-initiates the payment on the terminal. 
{
  "url": {
    "return_url": "https://yourpos.example.com/payment/return",
    "callback_url": "https://yourpos.example.com/payment/callback"
  },
  "order": {
    "amount": 39900,
    "currency": "NOK",
    "merchant_reference": "order-12345",
    "items": [
      {
        "id": "sku-coffee-001",
        "line_id": "1",
        "description": "Premium Coffee Beans 1kg",
        "quantity": 2,
        "amount": 39900,
        "vat_amount": 4275,
        "vat": 12
      }
    ],
    "store": {
      "id": "oslo-center",
      "terminal_id": "T0292",
      "payout_destination_id": "seller-1"
    }
  },
  "configuration": {
    "publish": [
      {
        "channel": "push",
        "type": "terminal"
      }
    ]
  },
  "profile_id": "your_profile_id"
}
Amounts are in the smallest unit of the currency. 39900 is 399.00 NOK.

​
After you create the session

​
Cancelling a payment

Once Dintero starts the transaction on the terminal, you can cancel it in two ways:
  • From the terminal — the customer or operator cancels directly on the device.
  • Via the API — call POST /sessions/{session_id}/cancel to cancel the session programmatically.
If the payment is successfully cancelled, the transaction is created with status DECLINED.

​
Receiving the result

Use the callback_url and webhooks to know when the transaction is authorized and captured. Terminal payments use auto-capture by default. See Checkout webhooks and transaction management.

​
Refund

seitatech.in_person supports both full and partial refunds. The refund requires a terminal_id in the request body, and the cardholder must be present at the terminal to approve by tapping their card. Refunds use the standard refund endpoint: 
POST https://checkout.dintero.com/v1/transactions/{transaction_id}/refund
Authorization: Bearer <token>
Content-Type: application/json

{
  "amount": 19950,
  "reason": "Partial return",
  "terminal_id": "T0292",
  "items": [
    {
      "line_id": "1",
      "amount": 19950,
      "quantity": 1
    }
  ]
}

​
Refund flow

  1. Your server sends the refund request. The API returns 202 Accepted and the transaction receives an INITIATE_REFUND event while the status remains CAPTURED.
  2. The terminal prompts the cardholder to approve the refund by tapping their card.
  3. The refund completes when the cardholder approves, or is voided if they cancel on the terminal.

​
Terminal requirements

The terminal must be active on the same payout_destination_id as the original transaction. It does not have to be the same terminal that processed the original payment. A valid terminal_id always returns 202 Accepted. If the terminal is offline, the INITIATE_REFUND event expires after 120 seconds and the transaction is updated with a failed refund event.
Use callback_url with report_event=REFUND or a webhooks subscription to receive a notification when the refund status is updated.

​
Quick reference: answers to common integration questions

QuestionAnswer
How do I enable in-person payments?Enable Seitatech In-person on a payment profile in Backoffice and reference it with profile_id.
Where does terminal_id go?order.store.terminal_id.
Is order.store.id enough?Yes - reuse the same store ID you already send. Just add terminal_id and payout_destination_id alongside it.
How do I trigger a sale?Create the session against an in-person payment profile with the order.store identifiers and a publish push/terminal configuration. The terminal prompts automatically.
How do I cancel a payment?Cancel from the terminal, or call POST /sessions/{session_id}/cancel via the API. The transaction status will be DECLINED.
How do I refund?POST /v1/transactions/{transaction_id}/refund. Both full and partial refunds are supported. Include terminal_id in the request body — the cardholder must approve on the terminal.
When is the refund complete?When the cardholder approves on the terminal. A valid terminal_id always returns 202 Accepted. If the terminal is offline, the INITIATE_REFUND event expires after 120 seconds and the transaction is updated with a failed refund event. Use callback_url with report_event=REFUND or webhooks to get notified.
Last modified on June 18, 2026