MARcet exposes two API families with distinct roles:

Merchant API – used by merchants/POS integrators to submit digital receipts and related sales data.
Payment Provider API – used by acquirers/PSPs/banks to initiate transaction records and receive receipt callbacks for reconciliation.

All requests use HTTPS and require authentication per integration agreement. Real-time submission is recommended; near real-time is supported.

Merchant API Documentation

Purpose. Standardised intake of ARTS Digital Receipt data from merchant systems.

Who uses it. Retailers, POS vendors, middleware/integration partners.

What it does

Accepts ARTS Digital Receipt payloads (with MARcet extensions where applicable)
Validates schema and business rules (Business Unit, Line Items, Tender, VAT and Totals)
Allocates receipt identifiers and makes receipts available for downstream delivery/search
Supports reconciliation via shared references (e.g., transaction/receipt IDs)

Details, endpoints, and examples are available in the Merchant API sections linked from the developer section.

Payment Provider API Documentation

Purpose. Enable acquirers/PSPs/banks to register payment transactions first and receive receipt callbacks once the corresponding merchant receipts arrive, enabling reliable reconciliation without polling.

Who uses it. Banks, acquirers, PSPs.

How it works

Transaction-first: The provider submits a payment transaction record (e.g., authorisation, capture, refund) with stable identifiers (provider or acquirer transaction ID, RRN, approval code, merchant reference if available).
Linking & matching: MARcet correlates incoming merchant receipts to provider transactions via the shared references.
Callbacks (webhooks): When a receipt is matched, MARcet calls back to the provider’s registered HTTPS endpoint with the receipt reference/payload needed for reconciliation.
Reliability: Callbacks are retried on failure (backoff strategy); idempotency keys prevent duplicates. Providers must expose an idempotent callback endpoint.
Security: Callbacks are authenticated and verified without bearer tokens — for example, via mutual TLS and/or signed callback headers (HMAC) as agreed per provider integration.
Reconciliation: Providers store the callback data to finalise payment↔receipt matching; exceptions are reported via provider-side processes or MARcet status queries.

Implementation details (fields, callback headers/signing, retry policy, idempotency rules) are documented in the Payment Provider sections linked from this page.

Security & Reliability (both Merchant and Payment Provider API)

Transport: HTTPS only.
Authentication: Per integration (e.g., mTLS, signed requests/callbacks, allowlisting).
Validation: Schema and business-rule checks on ingestion; structured errors/status returned.
Idempotency: Required for POSTs and callbacks; use stable transaction/receipt IDs.
Timing: Real-time preferred; near real-time supported with the same guarantees.

Questions?

Got any questions or don't find what you are looking for? We're always happy to help with your code or other questions you might have! Browse around and just let us know of any questions you might have, feel free to email us at support.