Skip to main content
A terminal session is a regular Checkout session with one addition: order.store carries the identifiers that route the payment to a specific terminal. The seitatech.in_person payment method is enabled through your payment profile.

​
Endpoint

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

​
Enable in-person payments via a payment profile

In-person payments are enabled on a payment profile in Dintero Backoffice → Settings → Payment Profiles. Enable Seitatech In-Person Payments on the profile you reference with profile_id, and the session will accept 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 it.

​
Where the terminal ID goes

The terminal ID belongs in order.store.terminal_id. The payment profile toggles the payment method on; order.store says which physical terminal the payment runs on. 
{
  "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.

​
Sale: full request

This example creates 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 Payments enabled, so no configuration block is needed. 
{
  "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"
    }
  },
  "profile_id": "your_profile_id"
}
Amounts are in the smallest unit of the currency. 39900 is 399.00 NOK.

​
When does the terminal start prompting?

Dintero starts the transaction on the terminal as soon as the session is created. You don’t have to do anything else. For the terminal to receive the payment request, we recommend including the following configuration in either the payment profile or the session request: 
"configuration": {
  "channel": "in_store",
  "publish": [
    {
      "channel": "terminal",
      "type": "push"
    }
  ]
}
seitatech.in_person must be the only enabled payment method on the session. Mixing it with other payment methods is not currently supported - configure a dedicated in-person payment profile for terminal sessions.

​
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 Payments 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. 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 12, 2026