Who Runa is
Runa is a payouts platform headquartered in London, with offices in New York and Sofia. Aron Alexander founded it in 2016 as WeGift, and in 2023 WeGift became Runa. The company behind it, The Runa Network Ltd, is registered in England and Wales. Its API sends value from a business to a person as a gift card, a prepaid Visa card or a push to the person's own card, all through one network. Each item in an order becomes a payout link: a web address where the person claims the brand the business chose, or picks one from a list the business allows.
The API is small and versioned by date. Orders are placed at /v2/order, the catalogue of brands is read at /v2/product and the balance that pays for orders at /v2/balance. Two webhooks, messages Runa posts to your server, report a finished order (order.completion) and a change to a brand (product.update). A separate Playground environment simulates orders with its own keys. Runa's documentation lists 40 supported countries, among them the UK, the UAE and EU countries such as Germany, France, Spain, Italy, the Netherlands, Poland and Romania, and its trust centre lists ISO/IEC 27001:2022 and PCI DSS v4.0.1. It delivers a reward without needing to know who receives it, which is why it is the reward delivery connector of our Rewards & referrals module.
What it does in your platform
Rewards & referrals
Delivers the rewards that are not money in the customer's own account: a gift card for a referral that counted, or for points a customer redeems. The platform decides from its own records that the reward is earned, its server orders it from Runa, and the customer gets the link in the app. Cash rewards into the customer's balance are paid by the Ledger and never pass through Runa.
How the connection works
Everything runs from the platform's server: orders through POST /v2/order, the catalogue through GET /v2/product and the balance through GET /v2/balance, with an API key in the X-Api-Key header. Runa's own security guide says a key must not be put in a mobile app or a web page, so the apps talk only to the platform.
A reward is earned
A customer's friend passes KYC and makes a first card payment within the 30 days your team set. The platform's own records say the referral counts, and this programme pays 25 euros as a gift card, not as balance. Nothing has gone to Runa yet: a click or a sign-up never reaches it.
The customer picks a brand
The app shows the brands your team allows, from the catalogue the platform keeps. It reads the catalogue with GET /v2/product, filtered by countries_redeemable_in and is_orderable, and the product.update webhook tells it when a brand changes its values or stops being orderable. Your rules can also pick the brand, or leave the choice to Runa's redemption page with a product list of type MULTIPLE or a payout selection template.
The server places the order
The platform's server sends POST /v2/order with one item: a face_value of 25.00, the brand's product code as a SINGLE product, a distribution_method of PAYOUT_LINK and a payment_method of ACCOUNT_BALANCE in EUR. The X-Idempotency-Key header carries a random key kept with the reward, so a retry after a lost connection returns the first answer and never a second gift card. The order's metadata holds the platform's reward ID. No name, email address or account detail is in the request.
Runa returns the link
In sync mode, which takes one item per order, the answer is the completed order with the link in items[].payout.url. In async mode, the default and good for up to 200 items, Runa answers PROCESSING and later posts the order.completion webhook; the platform checks its signature and reads the order with GET /v2/order/{id}. The platform shows the link in the app, the Notifications module tells the customer, and the Ledger records the order's cost against the marketing budget account.
The status comes back
Each link has a payout status: ACTIVE until the customer claims it, then CLAIMED, or EXPIRED if your account has link expiry switched on. Runa has no webhook for a claim, so the platform reads the status from the order and shows it in the Backoffice, next to the referral that earned it.
A failed or cancelled reward
If the order comes back FAILED, or Runa rejects it with insufficient_funds, the reward stays pending in the platform: it checks that the brand is still orderable, orders again with a new idempotency key or asks the customer to choose another brand, and alerts your team when the balance needs topping up. A link nobody has claimed can be cancelled by your team in Runa's portal, and its value returns to your Runa balance at the start of the following month; the platform reads the CANCELLED status and corrects the Ledger entry. A claimed link cannot be cancelled.
Next to other providers
Runa is the last step of a reward, never the judge of it. A referral tool such as Referral Factory, GrowSurf or Friendbuy, or a loyalty engine such as Talon.One, Voucherify or Open Loyalty, keeps the programme and its links or points. The platform decides what was earned, after the KYC / AML and Fraud & risk modules have checked the people and devices involved, and only then orders from Runa. None of those tools calls Runa directly. Cash rewards stay in the Ledger, which also holds what each gift card cost, and the Notifications module sends the message that a reward is waiting. Where a market's rules ban an incentive, the programme is switched off for that country and product, and no order is placed.
Runa is the module's reward delivery connector. The reward rules, caps, budgets, the record of every reward and its Ledger entries live in the platform, so moving to another gift card service later swaps a connector and leaves your apps' screens as they are. What is rebuilt in the new tool is the brand list with its product codes, the branded redemption page, the webhook endpoints and the balance that funds the orders. Links already issued stay with the provider that issued them.
When Runa fits best
A strong fit when
- You want some rewards delivered as gift cards from brands your customers know, in the UK, EU countries or the UAE, without sending the customer's name or email address to the provider.
- You want customers to choose the brand themselves, in your app or on a redemption page that carries your logo and colours.
- You want loyalty points to be redeemable for something outside the account, with each gift card ordered by your server and its cost recorded in the Ledger.
Also worth a look
- The Ledger alone, when every reward is cash in the customer's own balance: no delivery provider is needed.
- A tool your team already runs: its account becomes a connector too.
How we get you live
The contract
We help you get your Runa account and contract in place. Before live orders, Runa verifies your business with KYB and enhanced due diligence checks, which include business registration details and ID checks for key people, and we help you prepare them. The contract also settles whether unclaimed links expire, which Runa sets per account.
The data
With your team we agree which countries and brands customers can choose from, and build the redemption template in Runa's portal with your logo and colours. Orders use the PAYOUT_LINK method, so Runa receives an amount, a product and the platform's reward ID, and nothing about the customer. If you would rather Runa emailed the link, its EMAIL method needs the customer's email address, which then goes to Runa only for the programme they joined. Orders draw on the reward balance your team keeps with Runa: it can be topped up locally in 18 currencies, the euro and the pound among them, and brands priced in dirhams are paid from a US dollar balance through Runa's Embedded FX.
The keys
Production and Playground keys are separate, and Runa shows a key in full only once, when it is created. The production key goes straight into your platform's secrets, and we ask Runa to limit it to your servers' IP addresses. Each webhook endpoint has its own signing secret, kept in the same place, and a webhook without a valid signature is rejected.
A full test run
Every case runs first in Runa's Playground, at playground.runa.io: orders are simulated, the balance always covers them, links open a sample gift card page, and the X-Trigger-Error header produces an insufficient_funds or server error on demand. The Playground does not send webhooks, so we test those by sending example events from Runa's webhook portal. The first live order is a small gift card to your own team, claimed and checked against the Ledger before your first real customer.