Idram for online stores: the flow, the credentials, and how to enable it

If you sell to consumers in Armenia, some share of your buyers would rather pay from a wallet than type a card number. Idram is one of the wallets they use day to day, and adding it to a checkout is a different job from adding cards. Different contract, different credentials, different failure modes. This post covers all three.

What the buyer sees

The buyer experience is short, and it matters that you understand it, because it changes what your order page can promise.

1. The buyer reaches your checkout and picks Idram from the payment methods you have enabled for that domain. On the Paynet hosted checkout it appears as a wallet, under whatever display name you gave it.
2. They are sent to Idram to pay. Your site is out of the picture for this step, which is exactly the point: nothing sensitive passes through your server.
3. Idram confirms the payment back to Paynet, and the buyer returns to the return_url you set when you created the payment.
4. Your store confirms the real status and marks the order paid.

Step 4 is not optional decoration. The buyer's return to your thank-you page is a browser redirect, and browsers get closed, refreshed and shared. The status you act on has to come from the API, not from the fact that someone arrived at a URL.

What you need from Idram

You sign with Idram directly. Paynet does not resell wallet contracts and does not hold your money: Idram settles to you under your own agreement. What comes out of that agreement is two credentials plus three URLs.

The credentials. Idram issues an EDP Account ID, the field you will often see written as EDP_REC_ACCOUNT, and a secret key. That is the whole set. In Paynet they go into the provider you add for Idram, and they are stored encrypted at rest.

The URLs. Idram also has to register three addresses against your merchant account:

• a Result URL, which is how Idram confirms a payment,
• a Success URL, where a paid buyer is sent,
• a Fail URL, where an unpaid buyer is sent.

Paynet shows you all three, ready to copy, on the Idram provider screen in your dashboard. Send them to your Idram contact and ask for them to be registered. Do not skip the Result URL. Without it Idram has no channel to confirm your payments, and every sale will look unpaid to your store no matter how correct the rest of your setup is.

Turning Idram on in Paynet

Once you have the credentials, the dashboard part takes a few minutes.

1. Open Providers and choose Add provider. Pick Idram as the processor, give it a display name (this is the name buyers see at checkout, so keep it recognisable) and paste the EDP Account ID and secret key.
2. Connect the provider to your verified domain. A provider that is not connected to a domain will not appear at checkout on that domain.
3. Check the Domains page. Each domain shows which methods are active, and a domain with no active method shows "No payment method" rather than failing silently at the buyer's expense.

One thing you will notice: not every processor can have its credentials checked without taking a real payment. Where that is the case, the dashboard says so instead of pretending to verify them. That honesty matters for wallets, and it leads directly to how you test.

Testing when the wallet has no test environment

Idram does not offer a public test environment. Neither does Telcell. That means there is no wallet-side sandbox where you can fire imaginary payments at a fake Idram and watch them succeed.

What you can do is separate the two things you actually need to prove.

Prove your plumbing with the Sandbox provider. Install the Sandbox provider from your dashboard and either send "processor": "sandbox" or use a test API key that starts with sk_test_. No bank or wallet is contacted, no money moves, and nothing is counted against your balance. On the test checkout the card number picks the outcome: 4111 1111 1111 1111 is approved, 4000 0000 0000 0002 is declined by the issuer, 4000 0000 0000 0119 is a processor timeout, and there are numbers for insufficient funds, expired transactions and general failure. This is how you prove your order flow, your webhook handling and your thank-you page before real money is involved. It works inside the CMS plugins too, so you can test a real storefront end to end.

Prove the Idram credentials with one small real payment. When the sandbox run is clean, take a single live payment through Idram yourself. Paynet's pricing helps here: payments under 500 AMD are free, so a small self-test costs you nothing on the Paynet side. Confirm that the order completes in your store, that the transaction appears in your dashboard, and that a fiscal receipt is issued if you have e-HDM active.

Confirming payments correctly

Wallets make one architectural point unavoidable. Idram exposes no status API that Paynet can poll to ask "was this actually paid?" after the fact. The confirmation is the confirmation. Everything downstream of it therefore has to be robust.

The pattern the API is designed around is webhook as nudge, API as truth:

1. Paynet sends a webhook to the payment's callback_url, or the domain's webhook URL, on every final status and on refunds.
2. You verify the X-Paynet-Signature header, which is the lowercase hex HMAC-SHA256 of the raw request body under your webhook secret. Compute it over the raw bytes, never over a re-encoded copy of the JSON, and compare with a constant-time function.
3. You dedupe on delivery_id, answer 200 quickly, and then call GET /api/v1/orders/{order_id}/payment to read the authoritative state before touching the order.

Paynet waits 10 seconds for a 2xx, does not follow redirects, and retries three times, after 1, 5 and 30 minutes. If a delivery for a completed or refunded payment fails for good, you get an email, at most once per domain every 6 hours.

Two lifecycle details save real money here. A payment expires if it is unpaid after 20 minutes, and a late provider confirmation can move a failed or expired payment to completed. Always act on the latest state you read.

Working code for the signature check, in PHP and Node.js, is in the API reference.

Idram in the store plugins

If your shop runs on a supported platform you do not touch any of the API. Install the plugin, click Connect, and the processors you connected in Paynet appear at checkout, each as its own named option with its own logo. That covers WooCommerce, OpenCart 2, 3 and 4, PrestaShop, and the Tilda and Ecwid connectors, all listed on the plugins page.

The plugins take the same care with confirmation that the API asks of you. A webhook is only a hint to re-check an order, and the store then pulls the authoritative status from your Paynet account before completing anything. A forged webhook cannot mark an order paid.

Fiscal receipts for wallet sales

A wallet sale is a sale, so it needs a fiscal receipt like any other. With e-HDM connected and active, Paynet issues the receipt automatically for every successful payment, whatever method the buyer used, and the receipt QR is shown to the buyer. Receipts for payments taken through Paynet are free; standalone receipts cost 3 AMD each, and every new account starts with 500 of them. The details are on the pricing page.

What to do next

• Ask your Idram contact for your EDP Account ID and secret key if you do not have them yet.
• Add Idram as a provider in Paynet, copy the Result, Success and Fail URLs from that screen, and send them to Idram for registration.
• Connect the provider to a verified domain and confirm the domain shows Idram as an active method.
• Run the Sandbox provider end to end, including your webhook handler and thank-you page.
• Take one small live payment through Idram, under 500 AMD, and check it lands as paid in your store and in your dashboard.
• Questions along the way go to [email protected].

Idram is a trademark of its owner. Paynet is an independent payment gateway operated by Digital Brains LLC in Yerevan; merchants hold their own contracts with each provider.