# Kevmi — complete public knowledge Version: 2026-10-23.13 Updated: 2026-10-23 Website: https://kevmi.one This document is in English. It contains public product information only. API status and verified server events are authoritative for financial and account operations. # Quick start URL: https://kevmi.one/en/docs/quickstart Explore your workspace, set up your store and see an invoice as your customer will see it. This guide takes you through the main steps in order. 1. Explore the product Open the demo workspace to create a test order, explore payment links and check a fee calculation. The demo uses separate test data. It does not create a bank payment or transfer funds to a wallet. Open the demo workspace: https://kevmi.one/demo/index.html?lang=en Preview checkout: https://kevmi.one/en/pay/demo 2. Create an account with Telegram After Telegram sign-in, the merchant account opens. Website onboarding is at /account#applications; both the form and individual tracking at /account#applications/{id} stay inside the app. A new payment and card intent require the merchant’s latest website-review application to be approved. Approval alone does not connect the payment gateway. If the review changes after dispatch, the existing operation remains available for status reads, reconciliation and a requested bank code. Open your account: https://kevmi.one/en/account 3. Set up your store 1. Choose a store name your customer will recognize. 2. Choose a default VAT rule. Each new invoice separately accepts customer fee and VAT shares from 0 to 100%. 3. Select the notifications you want to receive in Telegram. 4. Use the calculator to check a typical order amount. Calculate fees and VAT: https://kevmi.one/en/pricing 4. Prepare a payment link Enter a clear order title, an amount and a currency. The customer gets a dedicated page with purchase details and the total due. An existing invoice keeps its original terms when your store settings change. Payment links guide: https://kevmi.one/en/docs/payment-links 5. Check payment availability Manage invoices, API keys, widgets and webhooks from your account. Before payment, Kevmi checks the gateway configuration, merchant approval, amount and invoice terms. If the selected method is unavailable, checkout explains why. For a new invoice in the interface, USD offers cards and Alipay; RUB offers SBP; USDT offers crypto. The API can also save USD + crypto for compatibility, but its live crypto payment is blocked with crypto_requires_usdt. USD and USDT are distinct, with no automatic conversion or assumed 1:1 rate. A crypto payment requires a separate USDT invoice. For a new live card or Alipay payment, the current gateway supports only feeCustomerPercent=0 and vatCustomerPercent=100: the merchant covers the entire processing fee and VAT is added in full for the customer. Other shares can be saved and calculated on an invoice, but execution is blocked with unsupported_allocation. The server never silently changes saved terms. SBP and USDT crypto payments support every processing-fee share and have no VAT. Creating an invoice, key or application does not charge money. Payout creation through the API is unavailable; withdrawal terms are covered in a separate guide. Gateway integration requirements: https://kevmi.one/en/docs/gateway # How Kevmi works URL: https://kevmi.one/en/docs/overview Kevmi brings individual invoices, payment methods and pricing rules into one workspace. Every order is paid separately. There are no subscriptions or automatic recurring charges. The merchant and the customer The merchant sets an order title, base price, currency and tax allocation. The customer opens a dedicated checkout page, chooses an available method and sees the total before confirming. The customer does not need access to the merchant workspace. Checkout exposes the details of one order, not the store balance, settings or other customer records. Four payment channels Method · Audience · Acceptance fee International cards · International customers · 10% + $0.50; 16% VAT SBP · Customers in Russia · 8%; no VAT Alipay · Customers in China · 10% + $0.50; 16% VAT Cryptocurrency · Crypto payments · 4%; no VAT Visa and Mastercard are available in more than 190 countries, except the published restrictions. Cryptocurrency is available in all countries. Countries and restrictions: https://kevmi.one/en/docs/geography Inside your workspace Server records belong to the verified account. The demo is separate and cannot create live payments or a withdrawable balance. Payment links and order terms: /account#links. Website applications and individual tracking: /account#applications. API keys, webhooks, widget and events: /account#keys, #webhooks, #widget, #events. Pricing, calculator, country map and full documentation: /account#knowledge. Store settings, Telegram notifications and support requests stay in the same account. Understanding the amounts The base price is the price of the goods or service before cost allocation. The fee and VAT use that base independently. Customer shares are added to checkout; merchant shares are deducted from the base price. Card and Alipay VAT is 16%, with fee and VAT allocation controlled separately. Kevmi’s platform commission is already included in the published fees. There is no additional 5% surcharge. A USDT TRC20 payout has a separate fee based on the source of funds and an explicit conversion quote. All fees: https://kevmi.one/en/pricing Access to features Documentation, the calculator and the documentation assistant are available without sign-in. Store settings, payment links and private support requests require an account. Financial availability is checked separately, and an unavailable payment channel is reported before a charge. # Payment and payout fees URL: https://kevmi.one/en/docs/fees The acceptance fee depends on the payment method and uses the order base price. Kevmi’s commission is included. VAT and payout fees are shown separately. Accepting one payment Add the percentage and fixed components. For a $5 card order, the fee is $0.50 + $0.50 = $1. VAT is $0.80 and is separate from this fee. The platform share, approximately 5% on average, is already built into these terms. Do not add a second platform percentage. Method · Percentage · Fixed fee · VAT International cards · 10% · $0.50 · 16% of the base price Alipay · 10% · $0.50 · 16% of the base price SBP · 8% · None · None Cryptocurrency · 4% · None · None Withdrawing funds The source of funds and payout network are separate settings. Using TRC20 does not make every payout fee the same. The payout fee is separate from the acceptance fee. Keep the fixed fee in its stated currency. Do not deduct RUB 400 from a USD amount or assume $3 equals 3 USDT. The final payout requires an explicit conversion quote. Source of funds · Payout fee · Destination Cards · 4% · USDT TRC20 Alipay · 4% · USDT TRC20 SBP · 5% + RUB 400 · USDT TRC20 Cryptocurrency · 0% + $3 · USDT TRC20 Calculation precision Invoice amountMinor is an integer: 500 means 5.00 USD, RUB or USDT in the explicitly stated currency. These are invoice calculation units; USD and USDT are not automatically converted. Fees and VAT use separate half-up rounding. For a crypto transfer, use the exact decimal coin amount and network returned by the created operation. Do not derive the transfer amount from the rounded invoice price. A calculation cannot produce negative merchant proceeds. feeMinor = roundHalfUp(baseMinor × rate / 100) + fixedMinor vatMinor = roundHalfUp(baseMinor × 16 / 100) // For SBP and cryptocurrency, vatMinor = 0 Check before paying The original order amount and currency. The payment method, which determines the fee and whether VAT applies. The VAT payer saved with the invoice. The customer total and expected merchant credit. Calculate your amount: https://kevmi.one/en/pricing Understand VAT: https://kevmi.one/en/docs/vat # VAT and cost allocation URL: https://kevmi.one/en/docs/vat VAT is 16% of the base order price for international cards and Alipay. The merchant sets a customer share from 0 to 100% and covers the remainder from revenue. SBP and cryptocurrency have no VAT under these published terms. One base for fees and tax The base price is the order amount entered by the store. The 10% + $0.50 fee and 16% VAT are calculated independently from this price. The fee does not apply to the VAT added on top. With a $5 base price, the fee is $1 and VAT is $0.80. Changing the payer changes the allocation, not the tax rate or its calculation base. The customer pays VAT This is the default VAT rule: a 100% customer share, equivalent to the legacy customer value. The merchant covers the entire fee in this example. VAT is added to the base price. Checkout shows the order price, VAT and total due. Only the acceptance fee is deducted from the base price. For a $5 order, the customer pays $5.80 and the merchant receives $4. customerTotalMinor = baseMinor + vatMinor merchantNetMinor = baseMinor - feeMinor The merchant pays VAT In this example, customer shares are 0% for both VAT and the fee. The legacy merchant VAT value corresponds to a zero customer VAT share; the merchant covers both costs from the base price. For a $5 order, the customer pays $5, the fee is $1, VAT is $0.80 and the merchant receives $3.20. VAT remains 16% of the base price; do not replace this rule with a 16/116 formula. customerTotalMinor = baseMinor merchantNetMinor = baseMinor - feeMinor - vatMinor A side-by-side example Amount · Customer pays VAT · Merchant pays VAT Base order price · $5.00 · $5.00 Acceptance fee · $1.00 · $1.00 VAT · $0.80 · $0.80 Customer pays · $5.80 · $5.00 Merchant receives · $4.00 · $3.20 Both columns assume a 0% customer processing-fee share. Intermediate VAT shares and separate fee allocation are available in the calculator. When the setting applies The store preference supplies the initial allocation. The interface and API save independent integer customer VAT and processing-fee shares from 0 to 100 for each invoice. Changes to store settings do not recalculate issued invoices. For a new live card or Alipay payment, the current gateway supports only feeCustomerPercent=0 and vatCustomerPercent=100: the merchant covers the entire processing fee and VAT is added in full for the customer. Other shares can be saved and calculated on an invoice, but execution is blocked with unsupported_allocation. The server never silently changes saved terms. SBP and USDT crypto payments support every processing-fee share and have no VAT. Create a new link for different terms. VAT is zero for SBP and cryptocurrency. Store settings: https://kevmi.one/en/docs/settings Check the calculation: https://kevmi.one/en/pricing Split processing fees and VAT: https://kevmi.one/en/docs/cost-sharing # Countries and payment methods URL: https://kevmi.one/en/docs/geography Visa and Mastercard cover more than 190 countries, except the published restrictions. SBP serves Russia, Alipay serves China, and cryptocurrency is available worldwide. Coverage by channel Channel · Coverage · Conditions International cards · More than 190 countries · Except the restriction list and five regions of Ukraine SBP · Russia · Availability depends on the bank and transaction Alipay · China · Availability depends on the account and transaction Cryptocurrency · All countries · Choose a supported coin and network The interactive map The Geography page has a two-dimensional world map. Filters highlight the published international card countries, Russia for SBP and China for Alipay. Search by country name or ISO code to see its methods and notes. Hatching marks Ukraine because five regions are excluded from cards. The rest of Ukraine is available. Card restrictions do not apply to cryptocurrency, which is available in all countries. Open the map: https://kevmi.one/en/countries What the list covers The complete list below describes international card coverage. Merchant registration countries and payout destinations have separate conditions. Approval depends on the issuing country, bank, card type and payment channel checks. A country being listed does not guarantee approval for every card or transaction. Visa and Mastercard restrictions Cards are unavailable in Crimea, Donetsk, Luhansk, Kherson and Zaporizhzhia. The rest of Ukraine is available. All other countries are available. Netherlands Antilles is preserved as a historical entry from the provider list; it does not block every modern Caribbean territory. Code · Country or territory AF · Afghanistan AQ · Antarctica BY · Belarus MM · Burma (Myanmar) BI · Burundi CF · Central African Republic TD · Chad CU · Cuba CD · Democratic Republic of Congo CG · Republic of Congo ER · Eritrea HT · Haiti IR · Iran IQ · Iraq LY · Libya ML · Mali NI · Nicaragua KP · North Korea RU · Russia SO · Somalia SS · South Sudan SD · Sudan SY · Syria VE · Venezuela YE · Yemen ZW · Zimbabwe UA-43 · Crimea (Region of Ukraine) UA-14 · Donetsk (Region of Ukraine) UA-65 · Kherson (Region of Ukraine) UA-09 · Luhansk (Region of Ukraine) UA-23 · Zaporizhzhia (Region of Ukraine) AN · Netherlands Antilles Country and territory directory Names, ISO codes and markers come from the shared country registry. These notes apply to international cards. ISO · Country or territory · Note AX · Åland Islands · — AL · Albania · — DZ · Algeria · — AS · American Samoa · — AD · Andorra · — AO · Angola · — AI · Anguilla · — AG · Antigua & Barbuda · — AR · Argentina · — AM · Armenia · — AW · Aruba · — AU · Australia · — AT · Austria · — AZ · Azerbaijan · — BS · Bahamas · — BH · Bahrain · — BD · Bangladesh · — BB · Barbados · — BE · Belgium · — BZ · Belize · — BJ · Benin · — BM · Bermuda · — BT · Bhutan · — BO · Bolivia · — BQ · Caribbean Netherlands · — BA · Bosnia & Herzegovina · — BW · Botswana · — BV · Bouvet Island · — BR · Brazil · — IO · British Indian Ocean Territory · — BN · Brunei · — BG · Bulgaria · — BF · Burkina Faso · — CV · Cape Verde · — KH · Cambodia · — CM · Cameroon · — CA · Canada · — KY · Cayman Islands · — CL · Chile · — CN · China · — CX · Christmas Island · — CC · Cocos (Keeling) Islands · — CO · Colombia · — KM · Comoros · — CK · Cook Islands · — CR · Costa Rica · — HR · Croatia · — CW · Curaçao · — CY · Cyprus · — CZ · Czechia · — CI · Côte d’Ivoire · — DK · Denmark · — DJ · Djibouti · — DM · Dominica · — DO · Dominican Republic · — EC · Ecuador · — EG · Egypt · — SV · El Salvador · — GQ · Equatorial Guinea · — EE · Estonia · — SZ · Eswatini · — ET · Ethiopia · — FK · Falkland Islands · — FO · Faroe Islands · — FM · Micronesia · — FJ · Fiji · — FI · Finland · — FR · France · — GF · French Guiana · — PF · French Polynesia · — TF · French Southern Territories · — GA · Gabon · — GM · Gambia · — GE · Georgia · — DE · Germany · — GH · Ghana · — GI · Gibraltar · — GR · Greece · — GL · Greenland · — GD · Grenada · — GP · Guadeloupe · — GU · Guam · — GT · Guatemala · — GG · Guernsey · — GN · Guinea · — GW · Guinea-Bissau · — GY · Guyana · — HM · Heard & McDonald Islands · — VA · Vatican City · — HN · Honduras · — HK · Hong Kong SAR China · — HU · Hungary · — IS · Iceland · — IN · India · — ID · Indonesia · — IE · Ireland · — IM · Isle of Man · — IL · Israel · — IT · Italy · — JM · Jamaica · — JP · Japan · — JE · Jersey · — JO · Jordan · — KZ · Kazakhstan · — KE · Kenya · — KI · Kiribati · — KW · Kuwait · — KG · Kyrgyzstan · — LA · Laos · — LV · Latvia · — LB · Lebanon · — LS · Lesotho · — LR · Liberia · — LI · Liechtenstein · — LT · Lithuania · — LU · Luxembourg · — MO · Macao SAR China · — MG · Madagascar · — MW · Malawi · — MY · Malaysia · — MV · Maldives · — MT · Malta · — MH · Marshall Islands · — MQ · Martinique · — MR · Mauritania · — MU · Mauritius · — YT · Mayotte · — MX · Mexico · — MD · Moldova · — MC · Monaco · — MN · Mongolia · — ME · Montenegro · — MS · Montserrat · — MA · Morocco · — MZ · Mozambique · — NA · Namibia · — NR · Nauru · — NP · Nepal · — NL · Netherlands · — NC · New Caledonia · — NZ · New Zealand · — NE · Niger · — NG · Nigeria · — NU · Niue · — NF · Norfolk Island · — MK · North Macedonia · — MP · Northern Mariana Islands · — NO · Norway · — OM · Oman · — PK · Pakistan · — PW · Palau · — PA · Panama · — PG · Papua New Guinea · — PY · Paraguay · — PE · Peru · — PH · Philippines · — PN · Pitcairn Islands · — PL · Poland · — PT · Portugal · — PR · Puerto Rico · — QA · Qatar · — RO · Romania · — RW · Rwanda · — RE · Réunion · — BL · St. Barthélemy · — SH · St. Helena · — KN · St. Kitts & Nevis · — LC · St. Lucia · — MF · St. Martin · — PM · St. Pierre & Miquelon · — VC · St. Vincent & Grenadines · — WS · Samoa · — SM · San Marino · — ST · São Tomé & Príncipe · — SA · Saudi Arabia · — SN · Senegal · — RS · Serbia · — SC · Seychelles · — SL · Sierra Leone · — SG · Singapore · — SX · Sint Maarten · — SK · Slovakia · — SI · Slovenia · — SB · Solomon Islands · — ZA · South Africa · — GS · South Georgia & South Sandwich Islands · — KR · South Korea · — ES · Spain · — LK · Sri Lanka · — PS · Palestinian Territories · — SR · Suriname · — SJ · Svalbard & Jan Mayen · — SE · Sweden · — CH · Switzerland · — TW · Taiwan · — TJ · Tajikistan · — TZ · Tanzania · — TH · Thailand · — TL · Timor-Leste · — TG · Togo · — TK · Tokelau · — TO · Tonga · — TT · Trinidad & Tobago · — TN · Tunisia · — TM · Turkmenistan · — TC · Turks & Caicos Islands · — TV · Tuvalu · — TR · Türkiye · — UG · Uganda · — UA · Ukraine** · Cards are unavailable in Crimea, Donetsk, Luhansk, Kherson and Zaporizhzhia. The rest of Ukraine is available. AE · United Arab Emirates · — GB · United Kingdom · — UM · U.S. Outlying Islands · — US · United States · — UY · Uruguay · — UZ · Uzbekistan · — VU · Vanuatu · — VN · Vietnam · — VG · British Virgin Islands · — VI · U.S. Virgin Islands · — WF · Wallis & Futuna · — EH · Western Sahara · — ZM · Zambia · — Coins and payment networks The catalogue contains 16 coins and 31 coin/network pairs. One coin can be accepted on several networks: USDT on Tron and USDT on Ethereum are different transfer options. The complete list appears below. Options available for a specific invoice and their limits come from GET /api/checkout/{token}/crypto-services. This page describes supported combinations; the current gateway response determines whether a payment can be created. A reference entry alone does not make an unavailable pair payable. The merchant creates a crypto invoice in USDT, and the customer chooses an available coin and network. The created gateway operation supplies the exact coin amount, address, QR code and expiry. A USDT invoice price does not lock the exchange rate of BTC, ETH or another coin, or imply a 1:1 rate. Transfer the exact decimal amount in the payment instructions without rounding or calculating a conversion yourself. USDT TRC20 is a separate merchant payout term. It does not restrict incoming payments to Tron or mean that payout creation is available through the account or API. The payouts guide explains withdrawal terms and restrictions. 1. Open the invoice and choose cryptocurrency as the payment method. 2. Choose a coin and an available network. The sender wallet’s network must match the network in the Kevmi payment instructions. 3. Create the payment instructions and check the exact amount, full address and expiry. Copy the address and amount, or use the appropriate QR code. 4. Send the specified amount on the selected network. Account for wallet or network fees so that the recipient receives the full amount shown in the instructions. 5. Wait for a confirmed status on checkout. Sending a wallet transfer alone does not complete the order: Kevmi verifies the result through the gateway. Coin · Name · Networks and gateway codes AVAX · Avalanche · Avalanche C-Chain (avalanche) BCH · Bitcoin Cash · Bitcoin Cash (bch) BNB · BNB · BNB Smart Chain (bsc) BTC · Bitcoin · Bitcoin (btc) DAI · Dai · BNB Smart Chain (bsc), Ethereum (eth), Polygon PoS (polygon) DASH · Dash · Dash (dash) DOGE · Dogecoin · Dogecoin (doge) ETH · Ethereum · Ethereum (eth), Arbitrum One (arbitrum), BNB Smart Chain (bsc) GRAM · Gram · TON (ton) LTC · Litecoin · Litecoin (ltc) POL · Polygon · Ethereum (eth), Polygon PoS (polygon) SHIB · Shiba Inu · Ethereum (eth) TRX · TRON · TRON (tron) USDC · USD Coin · Arbitrum One (arbitrum), BNB Smart Chain (bsc), Polygon PoS (polygon), Ethereum (eth), Avalanche C-Chain (avalanche) USDT · Tether · TRON (tron), Avalanche C-Chain (avalanche), BNB Smart Chain (bsc), TON (ton), Polygon PoS (polygon), Arbitrum One (arbitrum), Ethereum (eth) XMR · Monero · Monero (xmr) Do not use old payment instructions after expiry. If you have already sent funds, check the same operation and contact support if needed; do not create a second payment to check the first. Checkout: https://kevmi.one/en/docs/checkout#method Payout terms: https://kevmi.one/en/docs/payouts Checking a specific country The assistant can find a country by its Russian or English name or ISO code and explain its published marker. For ** countries, specify the location you need. For China *, ask about your card. If a country is absent from the list, this knowledge base cannot confirm international card coverage. Include the country, bank and desired method in a support request. Do not send a full card number or payment secrets. Geography: https://kevmi.one/en/countries Ask support: https://kevmi.one/en?support=open # Payment links URL: https://kevmi.one/en/docs/payment-links A payment link opens a dedicated order page. Customers see the seller, purchase description, available methods and total due on their phone or computer. What an invoice includes For a new invoice in the interface, USD offers cards and Alipay; RUB offers SBP; USDT offers crypto. The API can also save USD + crypto for compatibility, but its live crypto payment is blocked with crypto_requires_usdt. USD and USDT are distinct, with no automatic conversion or assumed 1:1 rate. A crypto payment requires a separate USDT invoice. Never include passwords, API keys, card details or bank codes in public descriptions. Use an order title and reference the customer recognizes. Store name, an order title of up to 120 characters and a description of up to 500 characters. Base amount and an explicit USD, RUB or USDT currency. Compatible methods, separate fee and VAT shares, an order reference and link expiry. Owner responses include link.payment with the saved state of an existing operation; this is separate from the link’s availability state. Any — the customer chooses Any selects all methods compatible with the invoice currency: cards and Alipay for USD, SBP for RUB, and crypto for USDT. The API takes a concrete methods array rather than the string any. Each method has its own quote. For a new invoice in the interface, USD offers cards and Alipay; RUB offers SBP; USDT offers crypto. The API can also save USD + crypto for compatibility, but its live crypto payment is blocked with crypto_requires_usdt. USD and USDT are distinct, with no automatic conversion or assumed 1:1 rate. A crypto payment requires a separate USDT invoice. For a new live card or Alipay payment, the current gateway supports only feeCustomerPercent=0 and vatCustomerPercent=100: the merchant covers the entire processing fee and VAT is added in full for the customer. Other shares can be saved and calculated on an invoice, but execution is blocked with unsupported_allocation. The server never silently changes saved terms. SBP and USDT crypto payments support every processing-fee share and have no VAT. Send methods through the API: https://kevmi.one/en/docs/payment-links-api#methods Creating a link 1. Open Payment links in your account. 2. Enter a title, amount, currency and description. Set fee and VAT shares with the two controls. 3. Keep Any to let the customer choose, or select specific methods. Set the expiration. 4. Compare the total for each method and preview checkout. 5. Receive the ready checkout link immediately after creation, then copy it for your customer or widget. If payment acceptance is unavailable, checkout reports this before confirmation. Creating an invoice does not charge money. Terms stay with the invoice A saved invoice does not change when store settings change. Its price, currency, fee and VAT shares, order reference and metadata belong to that order. This keeps the total consistent for a customer who has already opened the link. Create a new link and pause the old one when the price, description or cost allocation changes. Editing a URL amount cannot change the server calculation. A dedicated checkout page Server links are saved in the database and open across devices at /pay/… without merchant account access. A customer does not need to register to view an invoice. Store balances, settings and other customer records remain private. The /pay/demo example previews the experience without charging money. Browser demo links are test data and must not be presented as real invoices. Preview checkout: https://kevmi.one/en/pay/demo Checkout states: https://kevmi.one/en/docs/checkout Managing availability Pausing, cancelling or expiring a link blocks a new operation. It does not hide a dispatched payment: status, reconciliation and a requested bank code remain available. Link availability and financial state are checked separately. Resuming lifts a pause without changing terms. Cancellation is final, and an expired link cannot be extended. Create a new invoice for a new order or changed terms, not to retry a charge whose result is unknown. # Checkout URL: https://kevmi.one/en/docs/checkout Checkout shows the customer what they are buying, how they can pay and the amount due before confirmation. It is separate from the merchant workspace. Review the order Check the store name, purchase, base price and currency. If they differ from your agreement with the seller, ask for a corrected invoice before continuing. A public invoice only requires its address; access to the seller’s account is not needed. A demo page is clearly marked and does not collect card details for a real charge. Choose a method For a new invoice in the interface, USD offers cards and Alipay; RUB offers SBP; USDT offers crypto. The API can also save USD + crypto for compatibility, but its live crypto payment is blocked with crypto_requires_usdt. USD and USDT are distinct, with no automatic conversion or assumed 1:1 rate. A crypto payment requires a separate USDT invoice. Card: the browser encrypts payment details with the gateway public key. Kevmi relays the encrypted envelope; its server does not accept or store plaintext card numbers, CVV or one-time bank codes. A requested bank-code form appears only while the gateway’s challenge is valid. Alipay: the customer supplies a name and receives a QR code. SBP opens the bank payment URL; a gateway-provided QR can also be used. An expiry is shown when the gateway provides one. Crypto: choose a coin, then an available network from the current catalogue. After creating an operation, checkout displays the exact decimal amount, recipient address and two QR modes: address only, or address and amount. The wallet network must match the chosen network. A USDT invoice price does not lock another coin’s exchange rate: use the amount supplied by the gateway. Expired instructions are hidden while reconciliation continues for the same payment. For a new live card or Alipay payment, the current gateway supports only feeCustomerPercent=0 and vatCustomerPercent=100: the merchant covers the entire processing fee and VAT is added in full for the customer. Other shares can be saved and calculated on an invoice, but execution is blocked with unsupported_allocation. The server never silently changes saved terms. SBP and USDT crypto payments support every processing-fee share and have no VAT. Checkout states State · Meaning · Next step Active · The invoice is available to view · Check the total and the selected method’s availability Paused / expired / cancelled · No new payment can start through the link · Contact the seller; an original operation is checked separately Not found · The address is invalid or unavailable · Check the complete address Payment unavailable · A new operation is blocked by configuration, method, limit, allocation or merchant review · Follow the displayed message; saved invoice terms do not change Pending / action required · The original operation exists or needs confirmation · Complete the current step or check its status Result being checked · A confirmed result is not yet available · Check the original operation; do not create a second charge A network error or missing response does not prove that no charge occurred. An already dispatched operation remains readable even if the link no longer accepts new payments. What confirms payment Payment is confirmed by server reconciliation of the exact gateway operation. succeeded requires fulfillment_ready=true, verification=provider_confirmed, no dispute and an exact match between the paid amount and approved total. Crypto additionally requires confirmed settlement evidence. A redirect, widget message, accepted bank code or browser observation does not confirm money. After a timeout, read the original operation’s status; a replacement attempt is never created automatically. A new payment and card intent require the merchant’s latest website-review application to be approved. Approval alone does not connect the payment gateway. If the review changes after dispatch, the existing operation remains available for status reads, reconciliation and a requested bank code. Getting help Send the seller the invoice reference or address, the time of the attempt and the error shown. Do not send CVV, a banking password, confirmation code or seed phrase to support. The documentation assistant can explain terms but cannot independently confirm a credit. Payment help: https://kevmi.one/en?support=open VAT calculation: https://kevmi.one/en/docs/vat # Payments and statuses URL: https://kevmi.one/en/docs/payments An invoice describes an order. A payment is a specific attempt to pay it. A payment attempt and the availability of its link are separate states. The payment record The invoice stores order terms; payment identifies its gateway operation. The first launch reserves one durable binding and a server Idempotency-Key. After dispatch begins, another method cannot create a second charge on the same invoice. GET /api/payment-links and GET /api/v1/payments return link.payment to the owner. The link’s active/paused/cancelled/expired status is separate from payment state. A customer can only read their operation through the random checkout token. Data · Purpose Identifier and order · Associate the attempt with a purchase Base amount and currency · The calculation base Payment method · Applicable fee and tax VAT payer · Who covers the tax Fee, VAT and totals · Saved calculation Status and time · Current transaction state Gateway event reference · Server confirmation source Live operation states The demo uses separate test records. Changing a demo state does not confirm a real payment or change financial records. Status · Meaning pending · Operation created; awaiting action or a result requires_action · A bank code or customer confirmation is required processing · The provider is still confirming the result succeeded · The server verified the exact payment failed · Attempt ended without confirmed payment expired · Instructions expired; reconciliation remains available review_required · Additional review is needed; do not pay again partially_paid · Only part of the amount received; do not create another payment partially_refunded · Part of the payment was refunded refunded · Refund confirmed disputed · The operation is disputed The source of truth A signed webhook triggers an authenticated read of the exact gateway operation. IDs, order, currency, method, base and final amounts, live mode and monotonic version are validated. An incoming event name alone is not proof of money. State, receipt and the merchant event commit atomically. Older responses cannot overwrite a newer version; duplicates do not fulfil twice, and pending cannot replace a confirmed payment. These records do not automatically create a withdrawable balance or payout. When the result is unknown 1. Keep the original invoice and operation identifier. 2. Read GET /api/checkout/{token}/status; it does not create a charge. 3. Use POST /api/checkout/{token}/reconcile when explicit reconciliation is needed. 4. Do not change method, amount or idempotency key after an uncertain result. A timeout is not a decline. A lost response is recovered by the original server key; no replacement attempt is created automatically. # USDT TRC20 payouts URL: https://kevmi.one/en/docs/payouts Payout terms specify USDT on TRC20, with fees based on the source of funds. This guide covers fees, quote requirements and restrictions: payout creation through the account and API is unavailable. Fees by source The acceptance fee has already been included in the merchant credit. A payout is a separate operation with its own fee. Do not apply the acceptance fee to the balance a second time. Source · Fee Cards and Alipay · 4% SBP · 5% + RUB 400 Cryptocurrency · 0% + $3 Quotes and currencies Amounts in USD and RUB must be accounted for separately. Do not add them without an exchange rate. USD is a fiat currency and USDT is a digital asset; an automatic 1:1 exchange rate is not assumed. A quote must state the source currency and amount, fee, USDT output and expiration. Changes to the amount or wallet require a fresh check of the terms. Recipient address Use a TRC20 address belonging to the recipient. Address format validation can catch some typos but cannot verify the owner or guarantee delivery. Check the full address and network before sending. The server must validate the amount, available balance and quote independently of the client form. The payout process The demo uses a manually entered quote for calculation only. A test payout reserves demo funds and does not transfer assets. 1. Choose the source of funds and debit amount. 2. Enter a TRC20 address. 3. Get a current quote and review the fee. 4. Confirm the exact request terms. 5. Wait for a server-confirmed result. Payout availability Payout creation through the account and /api/payouts is unavailable. Published fees and a fee calculation do not create a transfer request or confirm its execution. Verified payments, receipts and events are kept in the history. These records are not a withdrawable balance. Executing a payout requires a separate funds ledger, a current quote, destination validation and transfer confirmation. Gateway integration: https://kevmi.one/en/docs/gateway # Sign in and register with Telegram URL: https://kevmi.one/en/docs/telegram-login Telegram verifies your identity. Kevmi creates your account on the first sign-in and opens it on later visits. A separate Kevmi password is not required. Signing in The request lasts five minutes. Start a new request if it expires. An old request cannot be reused to obtain a session. 1. Open Sign in or Create account and select Continue with Telegram. 2. Follow the bot link created by this browser. 3. Compare the six-digit code on the website and in the bot message. 4. Confirm in the private chat. 5. Return to the original browser. Your account opens after verification. Why the original browser matters The Telegram link is bound to a protected cookie in the browser that started sign-in. A challengeId or forwarded link alone cannot create a session on another device. You can confirm in Telegram on another device, but the account opens in the browser where sign-in began. Do not confirm a request you did not start. Sessions and sign-out A session lasts up to 24 hours. Its random token is stored in a Secure HttpOnly cookie and cannot be read by JavaScript. Website sign-out ends the current session. The bot command /logout ends all account sessions and cancels unused confirmations. A new sign-in requires a new request. Troubleshooting sign-in Situation · Action The link expired · Start a new request on the website A different browser is open · Return to the tab where sign-in began The codes differ · Do not confirm; start again Sign-in unavailable · Try later or contact support Temporary network error · Wait for the next check or retry sign-in Information used for sign-in The server receives a verified Telegram ID and available profile fields to create the account. A public username alone is not proof of identity. The bot does not ask for your Telegram password, banking codes, CVV, seed phrase or private keys. Authentication API: https://kevmi.one/en/docs/auth-api Sign in: https://kevmi.one/en/login # Store settings URL: https://kevmi.one/en/docs/settings Settings connect your store name, VAT rule and notifications to your verified account. Changes are saved on the server for the current user. Store name Choose a short, recognizable name that your customer expects to see on the order. The name must contain 1–80 characters after trimming surrounding spaces. A display name does not replace legal details or your customer agreement. Keep secrets, payment credentials and other people’s personal information out of this field. VAT payer The default payer is the customer. VAT applies only to cards and Alipay. Switching the setting does not change SBP or cryptocurrency totals. Existing invoices keep their saved terms. When creating an invoice, independent customer VAT and fee shares from 0 to 100% can override the defaults. The store preference only supplies a default for future invoices. A saved preference does not expand gateway capabilities. The current live card and Alipay channels require 100% customer VAT and 0% customer processing fee; other saved allocations remain calculations. Value · Rule for a new invoice customer · VAT is added to the customer base price merchant · The merchant covers VAT from the base price Telegram notifications Select payment, payout, support and security categories. Choosing a category controls notifications; it does not activate a payment channel or generate financial events. A test message checks delivery to the linked private chat. Its status appears in the notification center and GET /api/notifications. A queued message is not yet delivered; also check Telegram. Notification guide: https://kevmi.one/en/docs/notifications Saving and errors The form confirms a completed save. If the network fails, your input remains available for a retry; pressing Save alone does not prove the change was stored. Sign in again when your session expires. The server identifies the account from the session and does not accept another store owner ID from the browser. Theme and demo data The display theme is saved locally on the device. The demo workspace uses separate browser data and does not change the server account. Resetting the demo removes only test records in that browser. A demo export is not a bank statement or proof of payment. # Website and Telegram notifications URL: https://kevmi.one/en/docs/notifications Account events appear under the bell in the top bar. Read notifications, check Telegram delivery and open the relevant part of your workspace. Notification center The badge counts unread account events. Messages are grouped by date; Load more retrieves older records. Visitors are asked to sign in. Read state is stored on the server. Visible pages refresh automatically and open tabs synchronize read marks. Events newer than the last displayed message are not marked read along with older ones. 1. Select the bell in the top bar. 2. Choose all events or unread only. 3. Open the related page or mark a message as read. 4. Use Mark all as read for events already loaded. Event categories Support and security are enabled for a new account; payment categories are selected by the user. The center shows saved events for enabled categories. Browser demo events are not real fund notifications. Category · Contents Payments · Confirmed payment events Payouts · Confirmed payout events Support · Support requests and application stage updates Security · A new verified sign-in Test · Delivery check to your Telegram Configuring delivery Tests are limited to three per account per hour. A test does not change a balance or create a payment. Queueing a message does not prove delivery. 1. Sign in with Telegram and open Account → Notifications. 2. Enable the desired categories and save. 3. Select Test delivery. 4. Check the center status and the bot’s private chat. Notification settings: https://kevmi.one/en/account#notifications Delivery and read state are separate Delivery depends on Telegram availability and user permissions. A lost response can lead to a repeated message, but not a repeated financial operation. If delivery fails, check that the bot is reachable and not blocked. Application notification retries also run in background jobs; service interactions can trigger other queued deliveries. Check the notification center for the current status. Status · Meaning pending · Queued for processing sending · The server is attempting delivery sent · Telegram confirmed the send failed · Delivery failed The message delivery status refers to Telegram. Marking a notification read on the website does not mean it was read in Telegram and does not change delivery. Action confirmations The website shows a short notification after a completed save, new link or similar action. It closes automatically and stays longer when hovered or focused. This confirms the interface action. It does not replace a confirmed financial status or create a payment record. Field errors stay beside the form. Reading and marking through the API GET /api/notifications returns up to 30 account events, unreadCount and nextCursor. Pass nextCursor unchanged as cursor to load another page. unread=1 selects unread entries. Sort order is createdAt descending, then id descending. PATCH /api/notifications/read accepts either 1–100 ids, or all:true with before set to the timestamp in milliseconds of the last displayed event. A session, Origin and X-CSRF-Token are required. The client cannot set the record owner. The response contains updated, readAt and unreadCount. Reading an already-read event keeps its original readAt. Listing events does not mark them read; Telegram status and sentAt remain unchanged. { "ids": ["ntf_46d94180-492e-4c28-b15f-a70049161a63"] } API reference: https://kevmi.one/en/docs/api-reference Bot commands Command · Action /notifications · Manage categories /stop · Disable notifications /help · List available commands /logout · End all account sessions Feature availability The notification center requires sign-in. Telegram messages are sent to the verified private bot chat. If delivery is unavailable, check bot permissions and the message status. A payment or payout notification is based on a confirmed server event. Selecting a category changes delivery preferences, not transaction availability. # Support chat and requests URL: https://kevmi.one/en/docs/support The assistant explains Kevmi’s terms, finds the right page and helps with settings. Open chat using the round button at the bottom right. Use a private request for an account-specific question. Help on the current page On phones, chat opens in a compact panel. You can minimize and reopen it; a badge appears if an answer arrives while it is closed. Support opens on the current page. The former /help address redirects to the homepage with chat open. 1. Select the round support button at the bottom right or Ask your question. 2. Open an existing conversation or start a new one. Choose a suggestion or type a question: Enter sends; Shift + Enter adds a line. 3. Read the answer and follow its documentation sources. 4. Minimize chat to continue working. Messages and the draft stay in this browser. Open support chat: https://kevmi.one/en?support=open Conversations, drafts and history Keep each topic in a separate conversation. Search history by title or text, rename a conversation and pin important ones. A new conversation preserves earlier chats, and each keeps its own draft. Restore a conversation from Deleted, or permanently delete it after confirmation. History is stored in this device’s browser, survives page reloads and does not sync between devices, your account or Telegram. Clearing site data in the browser removes local history. If browser storage is unavailable, chat continues in the open page’s memory. Local conversations are separate from private support requests, which are stored on the server after sign-in. What answers are based on The website and bot use one versioned knowledge base. The server provides published guides, structured pricing, allocation and country facts, the page catalog and actual feature readiness to the generative assistant. The base includes applications, API keys, widgets and webhooks. Answer sources only refer to articles in that base. When confirmed information is insufficient, the assistant says so and suggests a more specific question or support request. It does not invent countries, payout times, limits or tax obligations. Follow-up questions and context The next question includes the selected conversation’s last three question-and-answer pairs, helping with follow-ups such as “What if the merchant pays VAT?”. Other local history is not automatically attached to the request. A short section label, such as Pricing or Checkout, is also sent. The URL, query parameters and invoice token are excluded. Prior messages are untrusted context and are checked against the knowledge base. AI and documentation search AI mode uses a configured provider, server storage and an available quota. /api/config reports configuration readiness; model connectivity is checked on a request. Unavailable generation, exhausted quota or an invalid answer falls back to labeled documentation search. Search also works without an external model. The assistant cannot read private accounts, balances, requests or payment data. It cannot charge funds, create payouts or change settings. Mode · Behavior ai · Writes an answer from the complete published knowledge and links relevant guides search · Returns matching published documentation Asking a useful question For example: “A $5 card order, with VAT paid by the merchant. What does the merchant receive?” Check exact figures in the published calculator. The chat field accepts up to 1,800 characters. If the connection fails, the question remains in the field for another attempt. Name the method: card, SBP, Alipay or cryptocurrency. For a calculation, give the base amount and both customer cost shares: fee and VAT. For an error, name the page, action and message shown. Do not send passwords, sign-in codes, tokens, CVV or seed phrases. Asking through the API POST /api/support/ask accepts question with 2–2,000 characters after trim. Optional history contains up to six messages with role=user or role=assistant. User messages accept 1–1,800 characters and assistant messages 1–3,000. Optional pageContext is a section label of 1–80 characters, without URLs, tokens, query parameters or line breaks. Optional locale is ru, en, es, de or fr and selects the response language. English is the default; complete technical sources are available in Russian and English. The API does not accept system messages, tools or arbitrary provider instructions. The JSON body limit is 65,536 bytes. The response contains mode, answer, sources, knowledgeVersion and needsHuman, with aiUnavailable:true when generation is unavailable. No user session is needed; a supplied Origin must match the application. API contract: https://kevmi.one/en/docs/api-reference Private support requests After sign-in, create a request with a subject of 1–120 characters and a message of 5–4,000 characters. It is stored in your account and is not visible to another user. The list shows the latest 30 requests. You can close your own request. Keep its reference when asking about status; resolution time depends on the issue. My support requests: https://kevmi.one/en/account#support # API reference URL: https://kevmi.one/en/docs/api-reference The server API supports accounts, invoices, secure checkout, statuses and webhooks. OpenAPI describes routes, fields and errors. Starting a payment requires a configured gateway, an approved merchant and supported invoice terms. Base URL and format The base URL is https://kevmi.one. Request and response bodies use JSON. Money values are integer minor units. Account and support dates are Unix timestamps in milliseconds. API responses use Cache-Control: no-store. The public /openapi.json can be cached for five minutes. Do not place cookies or secrets in a URL. curl 'https://kevmi.one/api/config' curl 'https://kevmi.one/openapi.json' Request authorization The web account uses an HttpOnly session cookie. GET /api/auth/me returns the current user and csrfToken. Mutations require X-CSRF-Token and a same-origin request. Scoped Kevmi merchant keys authorize /api/v1/payments, /api/v1/payment-links and /api/v1/events. They do not replace the session cookie for account settings or administrative routes. const me = await fetch('/api/auth/me').then(r => r.json()); if (!me.authenticated) throw new Error('Sign in required'); const response = await fetch('/api/account/settings', { method: 'PATCH', headers: { 'Content-Type': 'application/json', 'X-CSRF-Token': me.csrfToken }, body: JSON.stringify({ vatPayer: 'merchant' }) }); if (!response.ok) throw new Error('Settings were not saved'); const updated = await response.json(); Endpoint groups GET /api/config reports the presence of server configuration. GET /api/checkout/{token} returns invoice.availability for the selected method, including merchant approval and saved terms. These checks do not establish provider connectivity or payment success: the result comes from the verified gateway operation. Group · Purpose Config and health · Public service and storage readiness Authentication · Telegram challenges and sessions Account · Settings and the private merchant app /api/v1/payments · Scoped server invoice creation and reads; does not initiate a charge /api/v1/events · Server event log with events:read Integrations · Session-authenticated key and webhook endpoint administration Applications and moderation · Owned submissions, status tracking and separate moderator permissions Checkout · Public invoice, encrypted card request, concrete operation, bank code, status and reconciliation Gateway ingress · Signed v3 notifications and authenticated operation verification Support and notifications · Questions, private requests, events and read state Telegram · Verified bot webhook Unsupported money routes · Legacy direct /api/payments and /api/payouts do not create a charge or payout A public knowledge request The answer includes mode, answer, sources, knowledgeVersion and needsHuman. A supplied Origin must match the application origin. A server-side documentation agent can omit Origin. curl 'https://kevmi.one/api/support/ask' \ -H 'Content-Type: application/json' \ --data '{"question":"Who pays VAT?","locale":"en"}' Errors and limits An error includes a machine-readable code and a message. Unknown request fields are rejected. Standard JSON bodies allow 16,384 bytes; /api/support/ask and the Telegram webhook allow 65,536. 429 indicates a rate limit. 503 can indicate an unavailable integration, not a declined payment. Read error.code and do not change a financial status from an HTTP status alone. Error codes: https://kevmi.one/en/docs/errors Complete OpenAPI specification: https://kevmi.one/openapi.json # Payment links API and API keys URL: https://kevmi.one/en/docs/payment-links-api Create an invoice from your backend and receive checkoutUrl immediately. The API supports scoped keys, idempotent retries, independent fee and VAT shares, an order reference and private metadata. A server request returns a ready link POST /api/v1/payments and /api/v1/payment-links create the same invoice type. The payments route name does not imply a charge: the result is persisted invoice terms and a checkoutUrl for the customer. Send Authorization: Bearer , Content-Type: application/json and Idempotency-Key. Idempotency keys contain 16–100 letters, digits, hyphens or underscores. Persist one key for each logical order creation. curl 'https://kevmi.maxeevmax1.chatgpt.site/api/v1/payments' \ -H "Authorization: Bearer $KEVMI_API_KEY" \ -H 'Content-Type: application/json' \ -H 'Idempotency-Key: order-1042-create-v1' \ --data '{"title":"Design project · order 1042","description":"One-time payment for the agreed design work","amountMinor":500,"currency":"USD","methods":["card","alipay"],"vatCustomerPercent":100,"feeCustomerPercent":0,"orderId":"order-1042","metadata":{"campaign":"autumn"}}' The response contains link, checkoutUrl and replayed. Pass checkoutUrl to the customer or widget; keep the API key on your server. API key scopes and expiry Create a key at /account#keys in your verified merchant account. Its full value appears once; only a hash is stored. Keys last 90 days by default, with a permitted lifetime of 1–365 days and up to ten active keys per account. Grant only the required scopes. Revocation or expiry stops access. A key does not replace the browser session for account settings, endpoint administration, applications or moderation. Keep it out of widgets, URLs, public repositories and support messages. The website uses /api/payment-links with its session cookie, exact Origin and X-CSRF-Token. Those routes operate on the same owned invoices. Scope · Purpose invoices:read · Read owned invoices and their list invoices:write · Create invoices and change link availability events:read · Read the server event log API keys in your account: https://kevmi.one/en/account#keys Any and concrete API methods Any is an interface selection mode. New invoices accept methods: ["card", "alipay"] or a nonempty subset for USD; ["sbp"] for RUB; ["crypto"] for USDT. The value any is not an API payment method. For a new invoice in the interface, USD offers cards and Alipay; RUB offers SBP; USDT offers crypto. The API can also save USD + crypto for compatibility, but its live crypto payment is blocked with crypto_requires_usdt. USD and USDT are distinct, with no automatic conversion or assumed 1:1 rate. A crypto payment requires a separate USDT invoice. For a new live card or Alipay payment, the current gateway supports only feeCustomerPercent=0 and vatCustomerPercent=100: the merchant covers the entire processing fee and VAT is added in full for the customer. Other shares can be saved and calculated on an invoice, but execution is blocked with unsupported_allocation. The server never silently changes saved terms. SBP and USDT crypto payments support every processing-fee share and have no VAT. Any in the account interface: https://kevmi.one/en/docs/payment-links#any Checkout: https://kevmi.one/en/docs/checkout Fields and persisted terms The invoice saves the merchant name, price, currency, methods, both cost shares and calculated quotes. Metadata is returned to the owner and in server events, but not through public checkout. Do not store payment secrets in it. If shares are omitted, the merchant covers the fee; VAT inherits vatPayer or the account setting. A partial allocation can return vatPayer=shared. The title, orderId and description are public. Field · Rule title / description · 1–120 / 0–500 characters amountMinor · Integer 1–10,000,000,000; 500 means $5.00 in USD currency / methods · USD: card, alipay; RUB: sbp; USDT: crypto. Nonempty unique list. vatCustomerPercent / feeCustomerPercent · Independent integer customer shares from 0 to 100 vatPayer · Legacy customer or merchant; cannot conflict with the VAT share orderId · Optional, up to 100 characters; visible to the customer metadata · Up to ten string entries; key 1–40 letters/digits/_/-; value up to 500 characters; total up to 3000 UTF-8 bytes expiresAt · Future Unix ms within 90 days; seven days by default For compatibility, the API also saves USD + crypto, but live crypto execution is blocked with crypto_requires_usdt. Use USDT for new crypto invoices; no automatic conversion is performed. Cost allocation formulas: https://kevmi.one/en/docs/cost-sharing Retry after a network error Initial creation returns 201 with replayed=false. The same key and canonical body return 200, the original checkoutUrl and replayed=true. A different request under that key returns 409 IDEMPOTENCY_CONFLICT. Do not generate another key after a timeout. Repeat the original request with identical fields. Omitted values do not inherit changed settings again. orderId helps correlate an order but does not replace Idempotency-Key and is not required to be unique in storage. Reading and pagination GET /api/v1/payments returns links and nextCursor; GET /api/v1/payments/{id} returns one owned link. invoices:read is required. The default page size is 30; limit accepts 1–100. GET list and detail responses include link.payment: a summary of the related operation, or null when no operation exists. POST/PATCH responses may omit it; read the invoice again when you need the summary. Link status separately describes whether a new payment may start. Card fields and private keys are never included. Pass nextCursor unchanged through URLSearchParams. null marks the end; unknown and other merchants’ IDs both return 404. GET /api/v1/payments?limit=30 Authorization: Bearer Pause, resume and cancel PATCH /api/v1/payments/{id} with invoices:write accepts only {"status":"active"}, {"status":"paused"} or {"status":"cancelled"}. Cancellation is final. expired is derived from the expiry time; an expired invoice cannot be extended. Price, cost shares, description, orderId, metadata and expiry are immutable. Create another invoice for different terms. Changing availability emits invoice.updated, not a successful-payment event. The customer response GET /api/checkout/{token}?method=card returns the public invoice, quote, method availability and existing operation. Owner metadata, secrets and balances are not exposed. POST /api/checkout/{token}/pay requires the Site Origin and a concrete method. Card data is accepted only as sealed: {intent,jwe}, after the browser obtains /card-intent. Bank codes are encrypted and sent through /code. Crypto uses a saved USDT invoice and an available coin/network pair. A new payment and card intent require the merchant’s latest website-review application to be approved. Approval alone does not connect the payment gateway. If the review changes after dispatch, the existing operation remains available for status reads, reconciliation and a requested bank code. A missing live connection returns GATEWAY_NOT_CONNECTED; an incompatible allocation is never replaced with another calculation. Status and reconcile read the original operation without a duplicate charge. Checkout widget: https://kevmi.one/en/docs/widgets Confirm payment with webhooks: https://kevmi.one/en/docs/webhooks # Authentication and session API URL: https://kevmi.one/en/docs/auth-api Sign-in uses a short-lived challenge, Telegram confirmation and proof of control of the original browser. A Telegram ID supplied by the client is not proof of identity. Starting sign-in POST /api/auth/telegram/start accepts an empty JSON object {}. It requires the exact application Origin and an available bot. The server creates a challenge lasting 300 seconds and a protected browser-proof cookie. The 201 response contains challengeId, code, expiresAt and telegramUrl. The proof cookie is excluded from the deep link and is inaccessible to JavaScript. The limit is six starts per minute per hashed address. const response = await fetch('/api/auth/telegram/start', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: '{}' }); const challenge = await response.json(); // Show code and telegramUrl to the user. Waiting for confirmation POST /api/auth/telegram/complete accepts {challengeId}. It requires Origin and the original browser-proof cookie. Until confirmation, the response is 202 {status: "pending"}. After confirmation, 200 returns status=authenticated, user, csrfToken and expiresAt. A session is issued once. Expired challenges return 410; used or cancelled challenges return 409. const response = await fetch('/api/auth/telegram/complete', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ challengeId: challenge.challengeId }) }); if (response.status === 202) { // Poll again after a delay; do not create a new challenge. } Reading the session GET /api/auth/me returns 200 {authenticated:false} when no valid session exists. A signed-in response includes the user, CSRF token and expiration. The __Host-kevmi-session cookie lasts up to 24 hours with Secure, HttpOnly, SameSite=Lax and Path=/. The database stores a SHA-256 hash of its token. A profile form cannot read or replace the cookie. Account changes Mutations require the session, exact Origin and current X-CSRF-Token. Sec-Fetch-Site: cross-site is rejected. The server does not offer arbitrary CORS access. The account ID comes from the session, not request input. Missing and another user’s records do not disclose distinguishable ownership details. Signing out POST /api/auth/logout ends the current session and clears the cookie. Origin and CSRF are required; the body is not read. Telegram /logout also ends all account sessions. Cookies do not automatically move to another domain. When changing the service domain, update APP_ORIGIN and the bot webhook, then sign in again. # Errors and retries URL: https://kevmi.one/en/docs/errors API errors use a consistent format. The code is for application logic; the message explains the issue. Keep user input intact and offer a clear next step. One error format Responses do not include stack traces, SQL, tokens or a full external provider response. Do not display raw internal logs to a customer. { "error": { "code": "GATEWAY_NOT_CONNECTED", "message": "Financial operations are temporarily unavailable. Try later or contact support." } } Common error groups HTTP · Examples · Next step 400 · INVALID_JSON, UNKNOWN_FIELD, INVALID_INPUT · Check input and allowed fields 401 · AUTH_REQUIRED, SESSION_EXPIRED · Sign in again 403 · INVALID_ORIGIN, CSRF_REQUIRED · Check origin and current session 404 · NOT_FOUND, TICKET_NOT_FOUND · Check the address and ownership 409 · CHALLENGE_UNAVAILABLE · Start a new sign-in 410 · CHALLENGE_EXPIRED · Create a new sign-in link 413 · REQUEST_TOO_LARGE · Reduce the request body 415 · JSON_REQUIRED · Send application/json 429 · RATE_LIMITED · Reduce frequency and wait 503 · GATEWAY_NOT_CONNECTED, SERVICE_UNAVAILABLE · Check availability or try later Rate limits Action · Limit Start sign-in · 6 per minute per hashed address Check a challenge · 90 per minute per challenge Knowledge question · 12 per minute per hashed address with D1 Create a server link · 20 per minute per user Merchant API · 90 requests per minute per key New application · Five per day per user Resume application / moderator decision · 30 per minute per user for each action AI website review · 30 per hour service-wide Read checkout or attempt payment · 90 per minute per hashed address Create a support request · 6 per hour per user Test a notification · 3 per hour per user AI generation · 60 per hour service-wide by default Retry-After: 60 indicates a delay, not a guarantee that an hourly quota has reset. What can be retried A read can be retried after a delay on a temporary network failure. Before retrying a mutation, check whether the original completed; a lost response does not prove failure. Financial operations require idempotency and a server status check. A client redirect to a result page is not a substitute for confirmation. What to include in a request The page and action immediately before the error. Time, time zone and the visible error code. Your invoice or support-request reference, if available. A short description of the result you expected. Do not attach cookies, tokens, authorization headers, CVV or banking codes. # Integration security URL: https://kevmi.one/en/docs/security Trusted checks run on the server. The browser controls the interface, but cannot establish identity, financial status or final amounts. Sessions and ownership A valid server session identifies the account. Settings, requests, notifications and links are filtered by owner. A userId submitted from a form cannot replace that filter. Mutations additionally check Origin and CSRF. A public invoice URL exposes only that invoice and does not grant account access. Secrets stay on the server Secrets must not appear in Git, HTML, client JavaScript, OpenAPI examples, llms files or support messages. The public bot username is not a secret. Telegram bot token and webhook secret. External AI provider credentials. Payment gateway credentials and signing secrets. Session hashes and browser sign-in proofs. Financial checks The server reads saved invoice terms and checks ownership, merchant review status, currency, method and approved amount. URL values and browser calculations cannot change the price. A signed gateway notification triggers an additional authenticated operation read. Verified state, receipt and event commit together. Replays and older versions cannot confirm duplicate fulfilment. Card details and one-time codes are relayed only as encrypted envelopes. Do not add session recording, field-reading analytics or request-body logging to payment forms. Assistant boundaries The model receives public articles and facts, the page catalog, readiness flags, the question, three recent message pairs and a safe section label. It has no tools to read accounts or move money. Invalid structured answers or unverified sources fall back to documentation search. Website and user text are data. An instruction inside a question cannot alter fees or authorize a payout. Scope of the documentation The documentation does not assert a PCI DSS certification, banking licence, Merchant of Record status, guaranteed uptime or absolute security. Such claims require separate, documented confirmation. # Payment gateway integration URL: https://kevmi.one/en/docs/gateway The gateway processes financial operations. Kevmi connects them to orders, store settings and notifications. This guide describes the integration contract and availability checks. Checking availability Kevmi uses the gateway v3 API to create and recover operations, read statuses and reconcile results. The integration supports encrypted card and bank-code transport, Alipay and SBP QR payments, a crypto coin/network catalogue and incoming financial events. gateway.configured in GET /api/config reports whether the required connection settings are present. This endpoint does not probe the gateway; gateway.connected=false here means that connectivity has not been verified. For a specific invoice, read invoice.availability in GET /api/checkout/{token}: it checks the method, amount, terms and merchant approval. The compatibility field invoice.gatewayConnected mirrors availability.available and is also neither a health check nor a guarantee of payment approval. A new payment and card intent require the merchant’s latest website-review application to be approved. Approval alone does not connect the payment gateway. If the review changes after dispatch, the existing operation remains available for status reads, reconciliation and a requested bank code. Customer checkout contract Sensitive data is encrypted in the browser with RSA-OAEP-256 and A256GCM. The private key stays on the gateway. Kevmi validates that the intent belongs to this invoice and purpose, relays the envelope, and does not store plaintext card numbers, CVV, buyer name, email, bank codes or the envelope itself. Install the encrypted-transport extension on the gateway host before enabling cards. It checks the intent signature, expiry, replay, order and amounts. There is no plaintext fallback. This describes the protection mechanism, not PCI certification. Kevmi route · Purpose GET /api/checkout/{token} · Invoice, quote, method availability and existing payment POST /api/checkout/{token}/card-intent · One-time intent and public key for payment or code POST /api/checkout/{token}/pay · Start one operation; card uses sealed: {intent,jwe} POST /api/checkout/{token}/code · Encrypted one-time code for the current bank challenge GET /api/checkout/{token}/status · Read the original operation without another charge POST /api/checkout/{token}/reconcile · Explicitly reconcile the original operation GET /api/checkout/{token}/crypto-services · Current coins, networks and limits for a USDT invoice Hosting and gateway connectivity Kevmi supports Sites hosting on Cloudflare Workers with D1, and self-hosting on Node.js with SQLite. SQLite requires a persistent volume and backups. The payment gateway runs as a separate service with its own durable storage. An external gateway requires an HTTPS origin reachable by the server. In the self-hosted bundle, the server connects to a fixed gateway service on the private container network; the gateway service API is not exposed to the internet. The public site and callbacks use HTTPS. The browser also encrypts card details and bank codes before they reach Kevmi. localhost refers to the current server or container; it does not expose the gateway owner’s computer. Connection keys and secrets belong only in server configuration. For a custom domain, set a public HTTPS origin in NEXT_PUBLIC_SITE_URL before building. Documentation, canonical links and indexing resources use this value. It accepts only a scheme and host with an optional port, without a path, query, fragment or credentials. Match it to APP_ORIGIN in server configuration. Calculation and supported terms For a new invoice in the interface, USD offers cards and Alipay; RUB offers SBP; USDT offers crypto. The API can also save USD + crypto for compatibility, but its live crypto payment is blocked with crypto_requires_usdt. USD and USDT are distinct, with no automatic conversion or assumed 1:1 rate. A crypto payment requires a separate USDT invoice. For a new live card or Alipay payment, the current gateway supports only feeCustomerPercent=0 and vatCustomerPercent=100: the merchant covers the entire processing fee and VAT is added in full for the customer. Other shares can be saved and calculated on an invoice, but execution is blocked with unsupported_allocation. The server never silently changes saved terms. SBP and USDT crypto payments support every processing-fee share and have no VAT. Sending an arbitrary total_cents does not change the provider’s tax calculation. An actual amount that differs from the saved total enters review and cannot confirm fulfilment. Gateway business_balance fields are retained as settlement evidence, not treated as a Kevmi merchant balance. Connecting a live gateway Connecting the gateway includes server configuration, checks for the selected channels and processing verified financial events. Configuration readiness is checked separately from provider connectivity. A successful payment is accepted after verifying the operation status and amount. Deployment instructions are in ops/gateway-integration.md. 1. Deploy the Kevmi server and gateway as separate services. Configure durable storage, backups and the required background processes. 2. For an external connection, set an HTTPS origin in GATEWAY_BASE_URL. The self-hosted bundle uses its configured internal service. Both require a server-only GATEWAY_API_KEY and a separate GATEWAY_WEBHOOK_SECRET; secrets never reach the browser. 3. Set gateway BACKEND_WEBHOOK_URL to /api/gateway/webhook on Kevmi and a matching BACKEND_WEBHOOK_SECRET. 4. Enable encrypted card transport and keep its private key exclusively on the gateway host. Check public-key availability and matching intent-signing settings. 5. Check channel readiness, restrictions and the merchant website approval before launch. Webhooks and repeated events: https://kevmi.one/en/docs/webhooks Security: https://kevmi.one/en/docs/security # Webhooks: events, signatures and delivery URL: https://kevmi.one/en/docs/webhooks Register a public HTTPS endpoint, prove control and receive signed invoice and payment events. Delivery is queued durably; processing the same event again must be safe for your order. Where events come from invoice.created does not mean paid. Payment events come from a verified server operation after a current gateway read; an incoming event name alone is insufficient. Gateway → Kevmi ingress and Kevmi → merchant delivery are different legs with separate secrets. The browser, return navigation and widget messages do not set financial state. Event · Source invoice.created · Invoice persisted invoice.updated · Link availability changed payment.succeeded · Exact payment verified by the server payment.failed · Failed operation verified payment.refunded · Full refund verified payment.partially_refunded · Partial refund verified payment.disputed · Dispute verified payment.review_required · Operation requires additional review Register and verify an endpoint URLs cannot target IP addresses, localhost, private networks, nonstandard ports or contain credentials. DNS is checked before delivery; outbound POST requests do not follow redirects. An account can register up to five endpoints. The verification event has livemode=false. A successful HTTP status alone is insufficient: the challenge must match exactly. Rotating the secret requires verification again. 1. At /account#webhooks in your merchant account, enter a public HTTPS URL, description and the event types you need. 2. Save the issued secret in server-side storage. Its full value is shown once. 3. Verify signatures over the original request bytes. 4. Run endpoint verification. For endpoint.verification, return JSON echoing data.challenge: {"challenge":"the received value"}. 5. Enable the verified endpoint and inspect delivery history. Webhooks in your account: https://kevmi.one/en/account#webhooks Event envelope id stays the same across every delivery attempt of an event. createdAt is a Unix timestamp in milliseconds, and apiVersion identifies the contract version. data contains the persisted server object; the example is shortened. livemode=true distinguishes a real server event from endpoint verification. It does not mean an invoice is paid: check type and payment data. Handle known event types and validate the schema. { "id": "evt_example", "type": "invoice.created", "apiVersion": "2026-10-21", "createdAt": 1792540800000, "livemode": true, "data": { "invoice": { "id": "lnk_example", "orderId": "order-1042", "currency": "USD", "amountMinor": 500, "vatCustomerPercent": 100, "feeCustomerPercent": 0 } } } Verify HMAC-SHA256 Kevmi-Signature contains t=seconds,v1=hex. The signature is HMAC-SHA256 over the timestamp string, a dot and the original body: timestamp + "." + rawBody. Use the specific endpoint secret and a constant-time comparison. Reject signatures whose timestamp differs from server time by more than 300 seconds in either direction. Synchronize clocks. Do not parse and reserialize JSON before verification: whitespace and property order affect the signed bytes. import { createHmac, timingSafeEqual } from 'node:crypto'; function verifyKevmi(rawBody, header, secret, nowSeconds) { const match = /^t=(\d{10}),v1=([a-f0-9]{64})$/.exec(header || ''); if (!match || Math.abs(nowSeconds - Number(match[1])) > 300) { return false; } const expected = createHmac('sha256', secret) .update(match[1] + '.') .update(rawBody) .digest(); const received = Buffer.from(match[2], 'hex'); return expected.length === received.length && timingSafeEqual(expected, received); } // Read bytes before JSON parsing; cap the request body. // secret comes from your server secret store. const valid = verifyKevmi(rawBody, signature, secret, Math.floor(Date.now() / 1000)); if (!valid) throw new Error('Invalid webhook signature'); const event = JSON.parse(rawBody.toString('utf8')); // Validate the event schema and persist its ID together // with your order update in one database transaction. // Return a 2xx response after durable acceptance. This example covers signature verification. Your HTTP server also needs a body size limit, schema validation and transactional event persistence. Retries and acknowledgement Any 2xx response acknowledges an ordinary event. Persist the event durably before responding; expensive work can continue through your own queue. The response timeout is eight seconds. A network error or non-2xx response schedules a retry. There are at most six attempts: the initial delivery plus delays of one minute, five minutes, 30 minutes, two hours and 12 hours after successive failures. These are queue schedules, not guarantees of exact delivery time. Exhausting attempts marks the delivery failed. Delivery is at least once and does not promise strict ordering. Persist the unique event ID in the same transaction as your order update. An already applied duplicate should receive 2xx without fulfilling the order again. A manual retry restarts delivery attempts while preserving the original event ID, delivery ID and exact body. Each attempt gets a fresh signature timestamp. Pausing an endpoint preserves its queue; deleting it cancels pending and failed deliveries. Delivery history and reconciliation The interface shows endpoint state, recent deliveries, attempt counts, last HTTP response, error and next attempt time. These diagnostics complement your own order records. GET /api/v1/events with events:read returns up to 50 events and nextCursor. Pass the opaque nextCursor unchanged as cursor; null marks the end. Ordering uses both createdAt and id. The legacy before Unix-millisecond boundary remains available separately and cannot be combined with cursor. Verified endpoints receive subscribed events no earlier than their registration; paused endpoints keep accumulating queued events for delivery after resuming. This does not promise history from before endpoint creation. API keys and invoice creation: https://kevmi.one/en/docs/payment-links-api Incoming gateway receipt checks Gateway v3 posts to /api/gateway/webhook with X-Gateway-Event-Id, X-Gateway-Timestamp and X-Gateway-Signature: v1=. HMAC-SHA256 signs timestamp + "." + rawBody with GATEWAY_WEBHOOK_SECRET; the clock window is 300 seconds. Header/body ID equality, API version, live mode and body hash are checked. An event ID reused with different body bytes is rejected. A signed notification triggers an authenticated GET of the exact operation. Order, method, currency, base, approved total and version are checked. Success requires fulfillment_ready=true, verification=provider_confirmed, the exact paid amount and no dispute; crypto also needs confirmed settlement evidence. Ingress handling, receipts and merchant events are protected from duplicates. Old browser-only notification formats cannot establish successful payment. Merchant webhooks never contain card fields, bank codes, QR data, provider credentials or the gateway secret. Telegram has a separate contract POST /api/telegram/webhook verifies X-Telegram-Bot-Api-Secret-Token, the update structure and sender. update_id protects against duplicate processing. This route handles sign-in, commands, support and moderation actions; it does not accept financial receipts. The deployment owner configures the bot token, webhook secret, setWebhook registration and reachable HTTPS address. They are separate from the merchant endpoint signing secret. # Limits and availability URL: https://kevmi.one/en/docs/limits Payment availability depends on method, amount, country and the terms of a particular invoice. Check the total, restrictions and applicable processing time before confirmation. Adapter and channel limits Kevmi checks the ranges below before creating an operation. A payment channel may impose additional restrictions; an amount within range does not guarantee approval. Changing gateway configuration does not automatically change Kevmi limits. A new payment and card intent require the merchant’s latest website-review application to be approved. Approval alone does not connect the payment gateway. If the review changes after dispatch, the existing operation remains available for status reads, reconciliation and a requested bank code. Method · Amount checked · Kevmi range Card / Alipay · USD base price · $1–$1,000 SBP · RUB customer total · ₽1–₽100,000 Crypto · USDT customer total · 1–1,000,000 USDT + selected network limits Validation is not a commercial limit The calculator and API reject negative amounts, invalid currencies and calculations where the merchant’s allocated fee and VAT exceed the base amount. These checks protect data correctness. Passing arithmetic validation does not guarantee that a provider can accept the payment. Commercial and risk limits are checked separately by the payment channel. Refunds and disputed transactions Verified refunds, partial refunds, disputes and review states appear in the operation and merchant events. This does not imply that creating a refund or payout is implemented in the account. Do not fulfil again for payment.partially_refunded, payment.refunded, payment.disputed or payment.review_required. Preserve the original order/payment association and route disputed cases to an authorized operator. Recurring charges Kevmi has no subscriptions or recurring payments. Saving an order link does not authorize an automatic future charge. Each new order is paid separately. Readiness checks gateway.configured in /api/config reports the required gateway settings, while /api/health checks server storage. Neither establishes connectivity to a payment provider. Use invoice.availability in GET /api/checkout/{token} for a specific invoice’s terms; payment success is verified separately against the gateway operation. Integration requirements: https://kevmi.one/en/docs/gateway Ask about your use case: https://kevmi.one/en?support=open # Resources for search engines and AI URL: https://kevmi.one/en/docs/agent-access Public Kevmi information is available in server-rendered HTML, plain text and structured formats. These formats share one knowledge version and the same commercial facts. Public resources Address · Contents /docs and /en/docs · Full Russian and English guide editions /llms.txt · English index and core facts /llms-full.txt · Complete English knowledge text /knowledge.json · Facts, fees, articles and version /openapi.json · Implemented server API contract /sitemap.xml · Published public pages /robots.txt · Crawler directives Reading structured facts knowledge.facts.countries.card describes worldwide coverage with explicit restrictions. countryCount counts directory entries, coverageLabel is 190+, and exactList contains supported ISO entries. restrictions preserves the provider exclusion list. source=owner_provided and status=owner_list_received record the origin of the list. independentlyVerified=false and verifiedCountryCount=null mean the list has not been independently checked against a live gateway; it is still a received and published list. partialCoverage contains ** countries with incomplete location coverage. unresolvedFootnotes preserves the separate * marker for China. coverage=listed means inclusion in the list; partial_locations denotes location restrictions; footnote_pending denotes the separate unconfirmed meaning of a marker. None guarantees approval of every card. gatewayConnected=null and gatewayIntegration.liveConfigurationProvided=null mean that the static knowledge base does not contain a deployment’s current state. gatewayIntegration.availability identifies the endpoints for current checks. gateway.configured in /api/config reports settings, not provider connectivity. invoice.availability in the checkout response describes eligible invoice terms, while the compatibility field invoice.gatewayConnected mirrors availability.available. Neither replaces operation confirmation. gatewayIntegration.adapterImplemented=true describes v3 protocol support; subscriptionsSupported=false excludes recurring charges. { "subscriptionsSupported": false, "gatewayConnected": null, "countries": { "card": { "coverageLabel": "190+", "policy": "worldwide_except_restrictions", "restrictions": [ { "code": "AF", "name": "Afghanistan" }, { "code": "AQ", "name": "Antarctica" }, { "code": "BY", "name": "Belarus" }, { "code": "MM", "name": "Burma (Myanmar)" }, { "code": "BI", "name": "Burundi" }, { "code": "CF", "name": "Central African Republic" }, { "code": "TD", "name": "Chad" }, { "code": "CU", "name": "Cuba" }, { "code": "CD", "name": "Democratic Republic of Congo" }, { "code": "CG", "name": "Republic of Congo" }, { "code": "ER", "name": "Eritrea" }, { "code": "HT", "name": "Haiti" }, { "code": "IR", "name": "Iran" }, { "code": "IQ", "name": "Iraq" }, { "code": "LY", "name": "Libya" }, { "code": "ML", "name": "Mali" }, { "code": "NI", "name": "Nicaragua" }, { "code": "KP", "name": "North Korea" }, { "code": "RU", "name": "Russia" }, { "code": "SO", "name": "Somalia" }, { "code": "SS", "name": "South Sudan" }, { "code": "SD", "name": "Sudan" }, { "code": "SY", "name": "Syria" }, { "code": "VE", "name": "Venezuela" }, { "code": "YE", "name": "Yemen" }, { "code": "ZW", "name": "Zimbabwe" }, { "code": "UA-43", "name": "Crimea (Region of Ukraine)" }, { "code": "UA-14", "name": "Donetsk (Region of Ukraine)" }, { "code": "UA-65", "name": "Kherson (Region of Ukraine)" }, { "code": "UA-09", "name": "Luhansk (Region of Ukraine)" }, { "code": "UA-23", "name": "Zaporizhzhia (Region of Ukraine)" }, { "code": "AN", "name": "Netherlands Antilles" } ], "independentlyVerified": false, "approvalGuaranteed": false } }, "gatewayIntegration": { "adapterImplemented": true, "contract": "v3", "liveConfigurationProvided": null, "availability": { "source": "runtime", "configurationEndpoint": "/api/config", "configurationIncludesHealthCheck": false, "checkoutEndpoint": "/api/checkout/{token}", "checkoutIncludesProviderApproval": false } } } Public information boundaries Plain text and JSON do not contain sessions, tokens, private support requests, user payment records or integration secrets. Sign-in, account and checkout pages are excluded from search indexing. Reading public documentation does not grant store-management permissions. Personal records require a valid session and mutations require additional server checks. Updates and citations Articles have stable IDs, URLs, titles and an update date. Link to the relevant guide when citing an answer and preserve qualifications about transaction conditions. Sitemaps, llms resources and server-rendered HTML make content easier to extract. They do not guarantee indexing, search position or use by an external AI system. Only published translations have canonical URLs, hreflang alternates and sitemap entries. A locale configured for future translation is not a published language edition. # Split processing fees and VAT URL: https://kevmi.one/en/docs/cost-sharing Choose independently how much of the processing fee and VAT your customer pays on each invoice. Two sliders allocate each cost from 0 to 100% in one-percent steps, with the result visible before you create the link. Two controls for one order The processing fee control allocates the whole acceptance fee, including both its percentage and fixed components. The VAT control allocates only tax. Neither control changes the tariff, tax rate or base product price. Fully left assigns the cost to the customer; fully right assigns it to the merchant. Labels show both parties’ exact percentages and monetary amounts. Customer, Split equally and Merchant presets provide a quick choice. The customer share is added to the checkout total. The merchant share is deducted from the base order price. SBP and cryptocurrency have zero VAT, so the VAT control does not affect their total. Buttons and sliders work with the keyboard; animation is not needed to understand the result. Open the calculator: https://kevmi.one/en/pricing One base price, two separate costs International cards and Alipay cost 10% of the base price plus $0.50, with VAT of 16% of the base price. SBP costs 8% and cryptocurrency costs 4%; neither has VAT under the published pricing model. VAT is added from the base price, not extracted using 16/116. The fee is not recalculated on a total that includes VAT or the customer fee share. Kevmi’s commission is already included in the published tariff; another 5% is not added. fee = roundHalfUp(base × rate / 100) + fixed vat = vatApplies ? roundHalfUp(base × 16 / 100) : 0 customerFee = roundHalfUp(fee × feeCustomerPercent / 100) customerVat = roundHalfUp(vat × vatCustomerPercent / 100) merchantFee = fee − customerFee merchantVat = vat − customerVat customerTotal = base + customerFee + customerVat merchantNet = base − merchantFee − merchantVat Allocating a $5 card order Every example below uses a $5.00 base price, a $1.00 total card fee and $0.80 VAT. The percentages change only who covers those costs. Customer shares: VAT / fee · Customer pays · Merchant after deductions 100% / 0% · original default · $5.80 · $4.00 0% / 0% · merchant covers all · $5.00 · $3.20 100% / 100% · customer covers all · $6.80 · $5.00 50% / 23% · custom split · $5.63 · $3.83 The table illustrates allocation arithmetic. Of these card configurations, the current gateway can execute only 100% customer VAT / 0% customer fee. This calculation does not initiate a payout; there is no automatic USD-to-USDT conversion. Rounding without losing a cent Amounts are integer minor currency units. The total fee and total VAT are rounded separately first. Each customer share then uses half-up rounding, and the merchant receives the exact remainder of that cost. The two shares therefore always add up to the original amount. For a one-cent cost split 50/50, the customer is allocated one cent and the merchant zero. The percentage remains 50%, while monetary amounts reflect the currency’s available precision. The server rejects calculations with negative merchant proceeds. Set the split through the API Send vatCustomerPercent and feeCustomerPercent as integers from 0 to 100. Each applies to the invoice being created. Empty strings, fractional percentages and out-of-range numbers are rejected. Omitting feeCustomerPercent assigns the whole fee to the merchant. Omitting vatCustomerPercent uses the legacy vatPayer field or the account default. Legacy customer and merchant values correspond to 100% and 0% customer VAT. Do not send conflicting vatPayer and vatCustomerPercent values. Responses describe an intermediate VAT share as vatPayer=shared. Use the numerical percentage for new requests; shared is not accepted as the legacy vatPayer input value. { "title": "Design project · order 1042", "description": "One-time payment for the agreed design work", "amountMinor": 500, "currency": "USD", "methods": [ "card", "alipay" ], "vatCustomerPercent": 100, "feeCustomerPercent": 0, "orderId": "order-1042", "metadata": { "campaign": "autumn" } } The example uses the card channel’s supported allocation: all VAT to the customer and the full processing fee to the merchant. Saving other percentages does not make them executable. Create an invoice through the API: https://kevmi.one/en/docs/payment-links-api Terms stay with the invoice The invoice freezes the amount, currency, methods and both shares. Changing store preferences does not modify issued links. Sliders calculate the allocation; live execution depends on the connected channel’s capabilities. For a new live card or Alipay payment, the current gateway supports only feeCustomerPercent=0 and vatCustomerPercent=100: the merchant covers the entire processing fee and VAT is added in full for the customer. Other shares can be saved and calculated on an invoice, but execution is blocked with unsupported_allocation. The server never silently changes saved terms. SBP and USDT crypto payments support every processing-fee share and have no VAT. # Embed checkout on your website URL: https://kevmi.one/en/docs/widgets Open checkout in a modal, embed it in a page or send the customer to a dedicated payment page. The widget uses a public checkout URL and never needs a merchant API key in the browser. From invoice to checkout Create an invoice in /account#links and immediately receive checkoutUrl. Open /account#widget, paste the link and choose a modal, inline block or redirect. Keys and webhooks are available in neighbouring account sections. The builder preview always uses a demo order without charging. The generated widget code retains your live link, whose terms come from the saved server invoice. For a new invoice in the interface, USD offers cards and Alipay; RUB offers SBP; USDT offers crypto. The API can also save USD + crypto for compatibility, but its live crypto payment is blocked with crypto_requires_usdt. USD and USDT are distinct, with no automatic conversion or assumed 1:1 rate. A crypto payment requires a separate USDT invoice. Integration builder: https://kevmi.one/en/account#widget Payment links API: https://kevmi.one/en/docs/payment-links-api A button with a normal link fallback This example opens a demo without charging money. Replace both URL values with checkoutUrl from your invoice response. Load the script from the same Kevmi origin as the checkout URL. The href opens checkout when JavaScript is unavailable. data-kevmi-label gives the iframe an accessible name. Include the script once per page. Pay securely Three ways to open checkout Use a container such as div for inline mode and replace CHECKOUT_URL_FROM_API with a real URL. The frame adapts to its container width; checkout messages can resize its height within a bounded range. The modal closes with its button, Escape or a backdrop click. Focus returns to the original trigger after closing. Reduced-motion settings shorten the transition. data-kevmi-mode · Behavior · Useful for modal · An overlay dialog; the default mode · An order-level payment button inline · An iframe inside the selected container · A checkout step on your site redirect · Navigation to Kevmi in the current tab · A full payment page
Open checkout from your interface The kevmi:opened and kevmi:closed document events let your interface react to opening and closing. A kevmi:error event on the trigger reports an invalid checkout URL. None proves payment. Call the JavaScript API after the widget script has loaded. window.Kevmi.open(checkoutUrl, { mode: 'modal', label: 'Order checkout', closeLabel: 'Close checkout' }); // Inline blocks added after page load are detected automatically. // You may also request mounting explicitly: window.Kevmi.mount(document); What proves a successful payment Do not put API keys or signing secrets in HTML. The widget receives only a public link to one invoice. Checkout encrypts card details and bank codes with the gateway key; the Kevmi server does not accept them in plaintext. postMessage updates interface state, not order fulfilment. Check the message origin and source window before processing. Use a verified payment.succeeded event or a succeeded status in the server’s GET link.payment summary for the final result. Opening checkout, closing a widget or returning to the merchant site does not prove that money was received. Webhook signatures and delivery: https://kevmi.one/en/docs/webhooks Before adding the widget to production Allow the Kevmi origin in your Content Security Policy script-src and frame-src directives without broadening unrelated policies. Check narrow screens, keyboard access, and light and dark themes. Confirm the invoice is active, unexpired and has the correct price and cost shares. Keep an ordinary payment link as a fallback. Test failed deliveries and duplicate webhook events without issuing an order twice. # Apply to connect your store URL: https://kevmi.one/en/docs/applications Submit your website after signing in with Telegram and follow each review stage at a private URL. Automated checks support the reviewer; a moderator always makes the final decision. Submit an application Descriptions require 40–3000 characters; project names allow up to 100. The website must be accessible without signing in. URLs containing credentials, private hosts, nonstandard ports or query parameters are not accepted. The verified account owns the application. The entered Telegram contact is for communication and does not change ownership. Forwarding the tracking URL does not grant another account access. 1. Sign in or register with Telegram, then open /account#applications. 2. Enter a public HTTPS website address, project name, category and a description of your products or services. 3. Add a Telegram contact. Explain what customers receive and how orders are fulfilled. 4. Confirm your authority to submit the site and send the form. 5. Keep the /account#applications/{id} address that opens immediately after submission. Submit your website: https://kevmi.one/en/account#applications Four review stages The connecting line and stage markers reflect persisted server states. Reopening the page continues the same process. Closing the tab does not cancel your application; background jobs continue work and recover interrupted stages. Stage · What happens · Status shown Application received · Submission details and the private URL are saved · The first stage is complete Content review · AI compares the description with public website content · Running, complete or awaiting a specialist Technical checks · Availability and a bounded set of links are examined · A separate result and stage timestamp Specialist review · A moderator reviews the submission and findings · Awaiting decision, approved or a decline reason A yellow stage needs a specialist A yellow marker means that a stage needs attention, for example because information is insufficient, a link is unavailable or an automated result cannot be accepted confidently. It is not a final rejection. The status page explains the next step. A moderator can clear the current stage so the next check continues. A declined stage displays a cross and a user-facing reason that the moderator can edit before sending. Clearing an intermediate stage never removes the final manual review. What automated checks cover Checks examine the public home page: HTTPS, HTTP response, title, text and suspicious link patterns. They also request headers for at most three links on the same website. Redirect count, response size and request time are bounded. The checks do not access signed-in areas, execute downloaded files or replace a security audit or malware scanner. Completing a stage does not guarantee that every page is free of malicious content. Website content is untrusted data. Instructions on a website cannot assign an administrator, change Kevmi terms or approve an application. Unavailable AI and malformed model output require specialist review instead of silently passing the stage. Telegram updates Receiving an application, completing a stage, requesting specialist attention and making a final decision create notifications with a private tracking link. These use the Support category in account notification settings. Disabling that category stops the messages. The application event and notification outbox entry are committed together. Telegram delivery uses a retry queue and requires a connected bot. The tracking page remains the source of current status if Telegram is unavailable or the bot is blocked. Moderation receives separate alerts. Only users on the server moderator allowlist can clear a stage from Telegram; an old button cannot apply a repeated decision. Decline reasons are edited in the moderation workspace. Notification settings: https://kevmi.one/en/docs/notifications Application and decision contract Ownership comes from the session. Applicants cannot submit userId, status, roles or review results. Repeating creation with the same Idempotency-Key and body returns the existing application; changing the body with that key produces a conflict. A moderator decision applies only to the expected application version. Concurrent decisions save once; the other request receives 409. A decline reason is plain text of 10–1500 characters. Internal review evidence is restricted to moderators. Route · Access and behavior POST /api/applications · Session + CSRF + Idempotency-Key; 202 with a private url GET /api/applications · Current account applications GET /api/applications/{id} · Owned submission, stages and public history POST /api/applications/{id}/resume · Session + CSRF; continues processing applications only GET /api/moderation/applications · Verified moderators only POST /api/moderation/applications/{id}/decision · approve_step or reject, expectedVersion and a decline reason After the decision A new payment and card intent require the merchant’s latest website-review application to be approved. Approval alone does not connect the payment gateway. If the review changes after dispatch, the existing operation remains available for status reads, reconciliation and a requested bank code. If rejected, the merchant sees the reason and can correct the materials before applying again. A yellow stage means a specialist still needs to decide; it is not automatic approval. Support: https://kevmi.one/en?support=open Gateway availability: https://kevmi.one/en/docs/gateway