canonical: https://jentic.com/apis/nexigroup.com/nexigroup

# Nexi Group API

Nexi Group is the parent payments company that operates across the Nordics under brands such as Nets and Bambora. This API surface covers Swish checkout - the Nordic mobile payment scheme - and standard card payment processing through three endpoints: create a checkout session, process a payment, and retrieve a payment by ID. Authentication uses an API key passed in the Authorization header. The base host api.nexigroup.com is distinct from the Italian xpay.nexigroup.com gateway covered by the separate Nexi XPay spec.

## For AI agents

Create checkout sessions and process card or Swish payments through the Nexi Group Nordic API. Three endpoints cover session creation, payment, and payment status lookup.

## Scope

Does not handle refunds, captures, pay-by-link, or merchant onboarding - use for Nordic checkout session creation, payment processing, and payment status lookup only.

## Capabilities

- Create a checkout session with POST `/checkout/sessions` for embedded or redirected payment flows
- Process a card or Swish payment through POST /payments with the chosen payment method
- Retrieve the current status of a payment by ID via GET `/payments/{id}`
- Authenticate requests with an API key passed in the Authorization header
- Reach the Nordic Swish mobile payment scheme without integrating directly with each Swedish bank

## Use cases

### Nordic E-Commerce Checkout

Nordic merchants accept Swish, card, and other regional payment methods by calling POST `/checkout/sessions` to create a session keyed to the cart, then redirecting the shopper to the returned URL. Once the shopper completes payment, the merchant calls GET `/payments/{id}` to confirm the captured amount before releasing the order. This is the standard pattern for any merchant whose acquiring relationship sits with Nexi Group.

Example prompt: Create a checkout session for 499 SEK with a return URL pointing back to the merchant's order page

### Swish Mobile Payments

Swedish merchants accept Swish - Sweden's bank-backed mobile payment scheme - through Nexi Group rather than building direct integrations with each bank. POST /payments with the Swish payment method initiates the request, and the shopper approves it in the Swish app on their phone. GET `/payments/{id}` polls the result so the merchant knows when the funds have been authorised.

Example prompt: Initiate a Swish payment for 250 SEK from a customer's phone number and poll GET `/payments/{id}` until the status is final

### Status Polling for Order Fulfilment

Order management systems rely on GET `/payments/{id}` to confirm payment status before fulfilment. Because Swish and other asynchronous payment methods do not return a final result on the create call, the OMS calls the status endpoint with backoff until it receives a settled or failed state. Only then does the system trigger picking, packing, or digital delivery.

Example prompt: For payment id pay_456, poll GET `/payments/{id}` every 5 seconds for up to 60 seconds and report the final status

### Agent-Managed Payment Confirmation

An AI agent uses Nexi Group through Jentic to confirm payment status when a downstream event - a customer asking 'did my payment go through?' - needs an authoritative answer. The agent calls GET `/payments/{id}` with the merchant's reference, parses the response, and returns a clear confirmation or failure reason. Jentic supplies the API key in the Authorization header automatically.

Example prompt: When a customer asks about payment status, look up the payment by id and reply with a one-sentence confirmation or failure reason

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/checkout/sessions` | Create a checkout session for redirect or embedded flow |
| POST | `/payments` | Process a card or Swish payment |
| GET | `/payments/{id}` | Retrieve a payment's current status |

## Key resources

- **Checkout** — Create a checkout session for Nordic card and Swish payment flows
- **Payments** — Process payments and retrieve payment status by ID

## Why Jentic

- **Setup:** Wiring the Nexi Group API by hand means learning that its key rides in the Authorization header, pointing at the api.nexigroup.com host, and threading the payment id from checkout to status lookup yourself. Through Jentic you install once, import the Nexi Group API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** Nexi Group puts the payment id in the URL path (`/payments/{id}`), so a rule can pin your agent to reading status on one payment. You choose the operations it may call, so creating checkout sessions or processing payments is not included unless you add it.
- **Credential handling:** Your Nexi Group API key is stored once, encrypted, by your own Jentic One instance and injected into the Authorization header at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a Nordic checkout session' or 'get a payment status', and Jentic returns the matching Nexi Group operation with its schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Nexi XPay API** — Nexi XPay is the Italian gateway with 16 endpoints including hosted page, pay-by-link, refunds, and captures
- **Stripe API** — Stripe is a global payment processor that also supports Swish through PaymentIntents
- **Adyen API** — Adyen is a European acquirer with broad Nordic coverage and Swish support

## FAQ

### What authentication does the Nexi Group API use?

The Nexi Group API uses an API key sent in the Authorization header on every request. Through Jentic the key is held in the encrypted vault and Jentic injects it on each call, so the merchant credential never appears in the agent's prompt or log output.

### Can I accept Swish payments with the Nexi Group API?

Yes. POST /payments accepts Swish as a payment method, and the shopper approves the request in the Swish mobile app. Because Swish is asynchronous, the calling code must poll GET `/payments/{id}` to confirm the final state before fulfilling the order.

### How is the Nexi Group API different from Nexi XPay?

Nexi Group's api.nexigroup.com host covers the Nordic checkout flow with three endpoints - checkout session, payment, and payment status. Nexi XPay (xpay.nexigroup.com) is the Italian gateway with 16 endpoints including hosted payment pages, pay-by-link, refunds, and captures. Choose the API that matches the merchant's acquiring relationship.

### How do I confirm a payment status through Jentic?

Search Jentic for 'get the status of a nexi group payment', load the GET `/payments/{id}` schema, and execute with the payment id. Jentic injects the Authorization header automatically and returns the structured payment record.

### What currencies does the Nexi Group API support?

The Nordic surface covers SEK, NOK, DKK, and EUR for the markets where Nexi Group operates. The exact set available to a merchant depends on the acquiring contract; the spec accepts any ISO currency code in the request payload, but settlement is constrained by the merchant configuration on Nexi's side.

### Can I limit what my agent is allowed to do with the Nexi Group API?

Yes. Because you run Jentic One yourself, your own rules decide which of the three operations your agent may call and which credential it uses. You can pin the agent to reading status with GET `/payments/{id}` for a single payment id in the URL path, so it cannot create checkout sessions with POST `/checkout/sessions` or process payments with POST /payments unless you explicitly add those operations. Your API key stays with your instance and is injected into the Authorization header only for the calls you have allowed.