Operations
Code handling and fraud controls
A gift-card code is a bearer instrument: whoever reads it can spend it, and nothing about it can be un-spent. Every rule on this page follows from that. If you are assessing me as a buyer of your stock, this is the page that answers what you actually want to know.
The one-sentence version. Codes arrive over an API against a prepaid balance, are encrypted before they touch storage, are released exactly once to the marketplace order that paid for them, and every step is written to a ledger that is reconciled for a Japanese tax return.
01Sourcing
Codes are bought from distributor accounts programmatically, against a balance I have prepaid. There is no manual purchasing channel, no buying from individuals, and no accepting codes submitted by customers or third parties. A code that did not come out of a supplier API against an invoice I can point to does not enter the system at all.
- Every purchase request carries a provider order ID and a provider idempotency key. A retry after a timeout resolves to the original purchase rather than buying a second card — the single most common way an automated buyer quietly loses money and creates untracked stock.
- The unit cost, currency and settlement timestamp returned by the supplier are stored on the order. Cost is never re-derived from a price list afterwards.
- Stock is held either as a per-order purchase or as a small pre-bought reserve for the fastest moving denominations. Reserve items carry the same identifiers as direct purchases.
02Storage
The code is encrypted the moment it is received from the supplier, before anything writes it down. There is no state in which a readable code sits in a database column, a log line, an exception trace or a notification.
- AES-256-GCM with a 256-bit key, a fresh random nonce per code, and a versioned keyring so keys can be rotated without decrypting the archive.
- The encryption is bound to its own order through additional authenticated
data of the form
digital-order:<seller>:<order>. Ciphertext lifted out and replayed against a different order does not decrypt — it fails authentication. - A SHA-256 fingerprint of the code is stored alongside the ciphertext. The fingerprint is what the system reasons about; it can answer “have I seen this code before” and “was this the code delivered to this order” without any component having to read the code itself.
- Support tooling operates on fingerprints and on positional diffs. When a buyer mistypes a code, they are told which character position is wrong — not shown the code again.
03Issue — once, and only to a paid order
A code is released to exactly one marketplace order, the one that paid for it, through the platform's own digital-goods delivery channel. There is no email list, no messenger drop, no manual hand-off and no out-of-band delivery path that could put a code somewhere a platform cannot see.
- Delivery is recorded with a timestamp against both the order and the stored fingerprint.
- If a supplier ever returns a code whose fingerprint matches one already delivered, the pipeline treats it as a duplicate rather than as stock: it is not issued, and the supplier is flagged.
- Reserve items move to a consumed state with the order that consumed them. A used reserve item can never be re-selected.
04When a code does not work
It happens. Suppliers ship dead cards, regions get mismatched, and platforms occasionally void stock after issue. The response is fixed rather than negotiated.
- The buyer reports it in the marketplace order chat or by mail with the redemption error.
- I replace it from stock where a replacement exists. Where it does not, the order is refunded through the marketplace — which means the platform, not I, controls the money and the record.
- The failure is charged back to the supplier it came from, with the provider order ID.
- A supplier producing bad stock is automatically quarantined — its offers stop being selected for fulfilment until I clear it. This is enforced by the system rather than by me remembering.
- The customer-facing side of this is written up in the Refund Policy.
05What I will not do
These are not preferences. They are the boundary of the business, and they are why the supply chain above stays short enough to audit.
- No onward resale. Codes go to retail buyers on marketplaces. I do not sell to other resellers, do not supply bulk B2B lots, and do not operate a wholesale channel.
- No second-hand codes. Nothing is bought from individuals, forums, or customer submissions.
- No accounts, items or services. No game accounts, no farmed items, no boosting, no anything performed inside a game.
- No off-platform selling. There is no checkout on this website and there will not be one. Every sale is a marketplace sale with a platform-held payment.
06Audit trail
Every order carries its supplier, provider order ID, idempotency key, unit cost, currency, settlement time, delivery time, fulfilment state and code fingerprint. Any individual code can be traced from the buyer's marketplace order back to the supplier invoice it was bought on.
That trail is not decorative. It is reconciled into a Japanese sole-proprietor tax record — purchases as 仕入, marketplace settlements as revenue, with cost of goods sold computed against opening and closing stock. The books and the code ledger are the same data, which is the cheapest possible guarantee that the ledger is honest: an inflated or missing code would show up as a tax discrepancy.
07Who the buyers are
Retail consumers in Russia, buying a single card for themselves, through Wildberries and Yandex Market. Both platforms verify their sellers, hold the payment, run their own order records and expose my registration details publicly. Order sizes are consumer-sized; there is no bulk channel for a buyer to move volume through.
I am a Japanese sole proprietor, resident in Japan, and the business is taxed in Japan. The Russian retail side runs through my registered Russian sole proprietorship, which is what the marketplaces contract with. Both registrations are published on the front page and in the statutory disclosure, and I will answer verification questions about either of them directly.
08Verification
If you need more than a page to make a decision, ask. I can provide, to a counterparty under an NDA: my 開業届 and Japanese tax registration, Russian registration documents, marketplace seller-account confirmation, supplier account confirmations, purchase volumes with invoices, and a walk-through of the order pipeline on a live account.
Write to [email protected]. It is my own inbox.
This page describes controls that are implemented in the software running the business, not intentions. Where a control is enforced by code rather than by process, it says so.