Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.dintero.com/llms.txt

Use this file to discover all available pages before exploring further.

A terminal session is a regular Checkout session with two additions: the seitatech.in_person payment type is enabled, and order.store carries the identifiers that route the payment to a specific terminal.

​
Endpoint

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

​
The configuration.seitatech object

configuration.seitatech is not an empty marker object. It mirrors the shape of the other payment-type configurations such as dintero or klarna: 
{
  "configuration": {
    "seitatech": {
      "type": "payment_type",
      "in_person": {
        "type": "payment_product_type",
        "enabled": true
      }
    }
  }
}
FieldRequiredDescription
seitatech.typeoptionalAlways "payment_type". Identifies the kind of configuration.
seitatech.in_personrequired to enable in-person paymentsContainer for the in-person payment product configuration.
seitatech.in_person.typeoptionalAlways "payment_product_type".
seitatech.in_person.enabledrequiredSet to true to enable in-person payments on this session.
seitatech.in_person.payabilityoptionalUse "payable" (default) to allow payment, or "disabled" to list the method without making it selectable.
If your session profile already has Seitatech In-Person Payments enabled, you can omit the configuration.seitatech block from the request - the profile applies it for you. You only need to send the block when overriding profile defaults or when the profile does not have it enabled.

​
Where the terminal ID goes

The terminal ID belongs in order.store.terminal_id, not inside configuration.seitatech. The Seitatech configuration 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. 
{
  "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": {
    "seitatech": {
      "type": "payment_type",
      "in_person": {
        "type": "payment_product_type",
        "enabled": true
      }
    }
  },
  "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.
seitatech.in_person must be the only enabled payment method on the session. Mixing it with other payment methods is not currently supported.

​
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

Refunds for in-person payments use the standard refund endpoint. There is no terminal-specific refund flow. 
POST https://checkout.dintero.com/v1/transactions/{transaction_id}/refund
Authorization: Bearer <token>
Content-Type: application/json
Full refund: 
{
  "amount": 39900,
  "reason": "Customer return"
}
Partial refund with line items: 
{
  "amount": 19900,
  "reason": "One item returned",
  "items": [
    {
      "line_id": "1",
      "amount": 19900,
      "quantity": 1
    }
  ]
}
The refund is settled against the original card payment - the customer does not need to present the card again.

​
Quick reference: answers to common integration questions

QuestionAnswer
What goes in configuration.seitatech?A seitatech object with in_person.enabled: true. Not an empty {}. See the structure above.
Where does terminal_id go?order.store.terminal_id. Not inside configuration.seitatech.
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 with seitatech.in_person as the only enabled payment method. The terminal prompts automatically.
How do I refund?POST /v1/transactions/{transaction_id}/refund - same as e-commerce.