Paying an international service from Iran
There are usually five workable routes for paying a foreign service from Iran, and what decides between them is not price but who owns the account when you are finished. The shortest route is wherever the service itself sells crypto payment or prepaid credit; every other route adds an intermediary, and each intermediary carries one specific risk that can be named.
- Lesson 7 of 8
- Beginner
- Free, no signup
The question that has to be answered before price
When this is finished, does the account have to be yours?
Sign up yourself and intermediate only the payment
- first check whether the service itself sells crypto payment or prepaid credit
- if not, a virtual card or an app store gift card
- the email and password are yours from day one, and so is the renewal
The cheaper route exists, and this is what you accept
- the account is not in your name and the terms forbid transferring it
- the password and recovery email stay with the seller
- treat anything you write in that account as public
The right branch is not a bad route, it is a different route with a different cost. The mistake happens when someone takes the right branch while their real answer was the left one.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
Answer this first: what are you buying, and for how long?
There are three shapes of purchase and each one calls for a different route. A one off purchase, a tool or a template or a domain name, is the simplest case: it is paid once and if that once succeeds you are done. A monthly subscription is the hardest, because the question is not only today's payment but next month's renewal, and a route that worked today may not work then. Metered credit, such as topping up an API, is a third case that behaves more like the first: you put money in and it is spent gradually, with no automatic renewal that can fail.
The second question matters more and is usually not asked at all: when this is finished, whose account is it? If that account is going to be your working tool, the place where your projects and history and API keys live, then any route that hands you an account in somebody else's name is wrong from the start, however much cheaper it is. If you only want to try something for a month, the weighing is different.
Answer the third question in one sentence: if the payment fails or the account is closed, what do you have to follow it up with? A receipt from an anonymous seller in a foreign marketplace is not something you can point at anywhere. That answer usually picks the route for you.

The shortest route: when the service itself sells credit
Before reaching for an intermediary, open the service's own billing page once. More services take crypto directly or sell prepaid credit than people assume, and in that case there is no intermediary at all and the account is yours from day one.
A real example, also maintained on our buying AI accounts from Iran page: OpenRouter is a single API in front of models from several vendors, and it sells credit rather than a monthly subscription. Its own FAQ says it accepts "all major credit cards, AliPay and cryptocurrency payments in USDC", states the top-up fee as 5.5% with a $0.80 minimum on cards and 5% on crypto, and says it passes provider pricing through "without any markup on inference pricing". So the real cost is the vendor's own price plus the top-up fee, and nothing beyond that.
Now the position that sellers do not take: this route is not right for everyone. API credit is not a subscription, so nothing that lives inside the vendor app reaches you: no mobile app, no conversation memory, no projects. Someone who only wants to chat in a browser gets nothing out of this route and should look elsewhere. It pays off for people who write code or wire up their own tool. The percentage fee also bites on small amounts: a $0.80 minimum on a five dollar top-up is sixteen percent.
The other four routes, and the risk each one brings
When the destination only takes a card, four shapes of intermediary remain. The per service detail for each of them is maintained on the buying AI accounts from Iran page and stays current there; what matters in this lesson is the shape of the risk, because the shape does not change.
A virtual prepaid card. You buy a card number with a fixed balance and sign up on the vendor's own site yourself. Bitrefill sells virtual Visa and Mastercard for crypto. Its big advantage is that the account is yours from day one. Its risk is that a prepaid card is not a full substitute for a credit card and may simply be refused, and that next month's automatic renewal breaks mid use if the card balance has run down. The next lesson in this track opens that card up.
App store gift cards. If the service also sells its subscription inside the mobile app, the money comes off your App Store or Google Play balance, and both gift cards can be bought with crypto. Two risks: a gift card is tied to a country and a US code only loads into a US store account, and buying inside an app is usually more expensive than buying direct. One negative fact worth knowing, rechecked today: Bitrefill's catalogue carries no gift card for OpenAI, Anthropic or Midjourney, so this route only reaches subscriptions that are genuinely sold through the App Store or Google Play.
Reseller marketplaces. The cheapest and fastest route, and the same one that carries the most risk. You are buying from an anonymous seller, and what arrives is usually access to an account that is not yours. Nearly every one of these services forbids account transfer in its terms, so the account can be reclaimed or closed at any moment with nowhere to appeal. The password and the recovery email stay with the seller; treat anything you type into that account as readable by someone else.
Verification numbers. Some signups insist on a non Iranian mobile number. BitCall sells virtual numbers in more than 195 countries, says of its own OTP numbers that they are real, non VoIP numbers built to pass two factor verification, has no setup fee and no monthly subscription, and takes Bitcoin, USDT and Ethereum as well as cards and PayPal. Its risk is one sentence: a rented number is not yours, and if it lapses every account whose recovery hangs off that number goes with it. That clause alone is reason enough never to put a rented number on your main working account.
The four intermediary routes, and where each one breaks
Each cell is one of the four intermediary routes, with who owns the account at the end and where it breaks beside it. The direct route is absent here because it has no intermediary.
-
Virtual prepaid card
The account is yours. It breaks where the merchant refuses a prepaid card, or where the balance has run down by next month's renewal.
-
App store gift card
The account is yours. It breaks where the store account region does not match the gift card country, or where the service sells no in app subscription at all.
-
Reseller marketplace
The account is not yours. It breaks where the service forbids account transfer and the account is reclaimed or closed, with nowhere to appeal.
-
Rented verification number
The account is yours but its recovery key is not. It breaks when the rental lapses, or when the service recognises virtual number blocks and never sends the code.
This table is not an order from good to bad. The right route depends on the three questions in the first section, and for two people with two different needs the answer is two different cells.
Where the line actually is
This lesson is about services that publicly advertise these routes themselves, with the risk of each written next to it. Three things are deliberately absent here and will stay absent from every other lesson in this section: ways to hide an identity or a location, forging documents or identity details, and any technique whose purpose is to defeat detection. They are not left out as legal caution; what they teach is how to deceive the other side, and we do not teach that.
One distinction matters: terms of service are not the law. When a service's terms forbid account transfer, breaking that clause is not a crime, but the consequence is specific and has to be accepted with open eyes: the account can be closed, the money you paid does not come back, and there is nowhere to pursue it because you broke a clause you had agreed to. Someone who knows that and chooses anyway has made their own decision; someone who does not know it has been sold something.
And where the honest answer is "it is not clear", we write that. The standing of these routes under currency and tax regulation, and under the rules of the other side, is clear in places and not clear in others depending on what you are buying and from where, and it changes over time. We are not lawyers and this page is not legal advice. What this page can give you is an accurate list of the practical risks so that your choice is an informed one.
Check these four things before you pay
First, ownership. After the payment, whose email is on the account and who knows its password? If the answer is "the seller", you have bought a rental rather than an account, and it is better to know that now than in six months.
Second, next month. If what you are buying is a subscription, what exactly happens when the renewal date arrives? A prepaid card that has run empty breaks the renewal and the service cuts off mid use. A route that only works for today is not a route for a subscription.
Third, data. Treat anything you write inside a shared or purchased account as readable by someone else. For a trial account that does not matter; for an account where client files or API keys live, it is the only criterion that does.
Fourth, when it goes wrong. If the payment half completes or the account is closed, what do you hold that you can point at? A receipt from a known service in your own name is one thing; a Telegram message from an anonymous seller is another. Answer this before you pay, not after.
One habit makes all four cheaper: make the first payment the smallest one possible. Monthly rather than annual, the smallest credit pack rather than the largest. If the route works, scaling it up is one click; if it does not, you have kept the cost of the lesson to a minimum.
Four checks before paying, and four things that are not guarantees
The four checks
- Who holds the account email and password after the payment.
- What exactly happens at next month's renewal.
- Who can read what you write inside that account.
- What receipt in your own name you hold if it goes wrong.
These are not guarantees
- An automatic delivery badge, which speaks to delivery speed and not to how long the account lasts.
- A high seller rating, which belongs to past transactions and not to the service's terms.
- A replacement guarantee, which means nothing if the seller himself disappears.
- A price far below the official one, which usually means what you are buying is not what you think it is.
The right hand column is not a list of worthless things; they are things that feel reassuring, and not one of them answers the four questions on the other side.
The fast path, with AI
The usual way is to search the service name together with the word "Iran" and land on a forum thread from two years ago whose author was not sure either. The faster way is to go to the page that actually holds the answer and that almost nobody opens: the service's own billing page and terms of service. A language model is excellent at this, because the job is extracting a few specific clauses from a long legal text rather than knowing anything about Iran.
- On the service's own site find two pages: the billing or pricing page, and the terms of service. Copy their full text and keep the links.
- Put both into the recipe below. The recipe deliberately asks the model to quote the original sentence rather than summarise it.
- Read the quoted sentences yourself. Do not read the model's summary; the summary is exactly where a strict clause comes out sounding friendly.
- Now pick the route with the real answer in hand, and make the first payment the smallest one possible.
Copy-ready recipe
The two texts below are from a service's official site. The first is the billing or pricing page and the second is the terms of service.
[BILLING]
{full text of the billing page}
[TERMS]
{full text of the terms of service}
For each item below, if the answer is in the text, quote the exact sentence verbatim and say which text it came from. If it is not, write only "not in the text" and make no guess:
1. Which payment methods it names (card, crypto, prepaid credit, in app purchase).
2. Whether it has a supported countries list, and whether it requires the issuing bank of the card to be in those countries.
3. Whether it says anything about prepaid or virtual cards.
4. Whether it forbids transferring, selling or sharing an account, and in which clause.
5. Whether it also sells the subscription inside a mobile app.
Write no conclusion about what I should do and suggest no workaround. Only these five items.
Before you trust the output: A fast, cheap model of the Gemini Flash class is enough for this; our current pick is written up in the <a class="text-link" href="/ai/">AI section</a>. Three boundaries: a terms page says what the service <em>allows</em> and not what happens at the moment of payment, which the payment processor decides; a model summary can make a hard clause look soft, so the quoted sentence is the authority and not the summary; and a card number, a password or a one time code never goes into a chat.
AI in this kind of work
Here AI does one thing very well: pulling a few specific clauses out of a long legal text you pasted yourself. What it should not be asked is whether a service works in Iran, answered from its own memory; supported country lists change, and the model's answer is a recollection rather than a lookup.
Tools that actually help
- Claude For pasting a whole terms of service and getting exact quotations of the clauses. It holds long text well, which is what this job needs.
- Gemini The same job at a lower cost. For clause extraction from text already in front of the model, the fast cheap tier is enough.
- NotebookLM For comparing several services at once: you load each one's terms as a source and ask against those sources rather than the model's memory.
Where it backfires
Two risks, and the first is the one people take less seriously. One: if you ask a model how to get around a restriction, the answer is usually something that breaks that same service's terms and gets your account closed. That is not the useful question; the useful question is what the service itself permits. Two: card numbers and login details do not get pasted into a chat. Google writes in the Gemini Apps privacy notice that "a subset of chats are reviewed by human reviewers" and says plainly "please don't enter confidential information that you wouldn't want a reviewer to see", with human reviewed chats retained for up to three years. The text of a terms of service is public and pasting it is entirely fine.
Sources: Gemini Apps Privacy Notice, Google
Where this advice stops
This lesson gives you the shape of the routes and their risks; it cannot tell you whether a particular service will accept your card today. That decision is made at the moment of payment by that merchant's payment processor and no page can guarantee it in advance. The intermediaries' own terms are not fixed either: prices, countries and what is in the catalogue change every few months. The facts on this page were read from those services' own sites on 7 September 2026, and the buying AI accounts from Iran page is where they are kept current. There are no affiliate links and no discount codes here, and RGB takes no money from any of these routes.
From our own work
The buying catalogue behind our buying AI accounts from Iran page has one rule worth copying: before printing any route, rgba_buy_route_printable checks two things and drops the whole route from the page if either is missing. First that a source with the date it was read is recorded, and second that the risk text is filled in all four languages. So a route with no downside written for it does not appear on that page at all. The reason is written in the file itself: a route with no downside is an advertisement, not a reference. Prices and affiliate links are deliberately absent from that same file.
Real follow-up questions
Which route is the cheapest?
Usually a reseller marketplace, and that is also the riskiest, because the account is not yours and the terms forbid transferring it. If your purchase is a one off and low stakes that is not a bad trade; if the account is going to be your working tool, weigh the saving against the account being closed and taking all of your work with it.
Why does a payment with a virtual card get declined?
Because the merchant's payment processor can see at that moment that the card is a prepaid one and which country issued it, and some merchants decline on exactly that basis. The decision is made on the merchant's side and the error message usually explains nothing. The virtual cards lesson in this track opens that up.
Is buying an account from a reseller illegal?
Breaking a service's terms is not the same thing as being illegal, and we are not lawyers and will not opine on the second. What we are sure of is this: nearly all of these services forbid account transfer in their terms, so the account can be closed at any moment, the money does not come back, and there is nowhere to pursue it. Know that practical risk before you buy.