All Merchant API traffic uses HTTPS and authenticated requests. We verify the sender, validate payloads, and protect data in transit and at rest.
Transport
All requests must use HTTPS (TLS). Weak ciphers are not supported.
Bearer authentication
Authentication is performed with Bearer tokens over HTTPS (TLS) on every request. Kwick accepts requests that include a valid Bearer token. You obtain your token for the machine user account after logging in to the Partner portal. Keep tokens secret and rotate them regularly.
Failure modes
Missing/expired/invalid token → 401 Unauthorized. Insufficient permissions → 403 Forbidden.
Digital signature
Each DigitalReceipt is digitally signed by ETNetwork. The signature is a checksum/hash signed with a private key and embedded at //DigitalReceipt/Signature.
To verify:
- Compute the checksum/hash for the received
DigitalReceipt(excluding theSignatureelement). - Verify the embedded signature using the public key.
- Compare: your computed checksum must match the verified value.
Get the public key
The public key is provided by ETNetwork. Keep it up to date and verify its provenance before use.
Validation
All receipts are validated on ingestion (schema + business rules for ARTS Digital Receipt and any MARcet extensions). On failure, the API returns structured status and error details so you can correct and retry.
Idempotency (recommended)
Use a stable, unique receipt identifier for every POST so that retries are safe and do not create duplicates. Prefer identifiers that are stable in your POS/export pipeline and include them in logs and support tickets.
Rate limits & payload size
Requests above documented limits may receive 429 Too Many Requests. Very large payloads may be rejected with 413 Payload Too Large.
Timeouts
Set client timeouts to accommodate network variance; the service may close idle connections.