Frequently asked questions

Tiki is an employee benefits and loyalty platform: it lets a company issue digital gift cards, run meal vouchers, steer cashback programmes and pay amounts in bulk into its beneficiaries' wallets.

No. The four blocks share the same foundation but activate independently. You can start with meal vouchers and add gift cards later, without recreating your beneficiaries.

The HR, payroll or administrative teams who prepare and approve distributions, and finance for tracking and exports. Rights are set by role, so each person sees only what concerns them.

Opening a company space and configuring a standard programme is quick; the real timeline depends on declaring your beneficiaries and, where applicable, integrating with your systems.

At merchants affiliated to the network, within the categories your programme permits. A meal voucher is restricted to food merchants; a gift card can cover a broader scope that you define.

Yes, per batch or per card. The balance stays visible until the last day; after expiry, the residual is identified line by line on the batch concerned.

You describe the trigger — merchant, category, minimum amount — and the reward, as a percentage or a fixed amount, then set caps per beneficiary and the overall budget before activating the rule.

Yes. The same beneficiary can hold a meal wallet, a gift wallet and a cashback wallet, each with its own rules of use and its own balance.

The portal's operations — create a beneficiary, issue a card, credit a wallet, upload a payout batch, read a balance — are exposed through the REST API, with the same rights model.

Yes: an isolated environment with its own keys and disposable data, to run the full integration before switching to production. The calls are identical across environments.

Through signed webhooks: you declare a URL and the events you care about, and verify the signature on arrival. Failed deliveries are retried and their history is available.

Only the users you have invited, and according to the role you gave them. Isolation between organisations is enforced at the query, not by filtering the display.

Every issuance, top-up, spend, cancellation and configuration change is timestamped, attributed to its author, and remains available to view and export.

Generate one key per integration so you can revoke one without breaking the others, never put them in client-side code or a repository, and rotate by creating the new key before revoking the old one.