Privacy policy

Pepe Pay is software that manages virtual cards issued by external card providers. For the data described below, the Pepe Pay operator is the controller.

The operator’s legal identity and registered address are not published, because they have not been verified. Pepe Pay is not naming an unverified entity or address, and this policy does not replace verified details. See the contact page.

This policy covers the bot, the Mini App and this website. It does not cover the card provider: to issue and operate a card, the provider processes your data as its own controller, under its own privacy policy. When you pay a merchant, that merchant and its payment stack process your data as well.

Scroll the table horizontally to read all columns.

Pepe Pay does not persist full card numbers, CVV codes, PINs, static 3-D Secure passwords or one-time 3-D Secure message text. Card records contain masked data. Private card details are fetched from the provider only for a short display window requested by the card’s owner, or by a member whose team grant for that card is active. Access is checked again before a sensitive response is returned, so a grant revoked while the issuer read is in progress cannot receive a late response. Automated delivery fetches issuer 3-D Secure messages, not the private PAN, CVV or static-password reveal. Automatic delivery goes only to the card owner’s own channels; a team member reads codes in the app while the grant is active. Both are handled transiently for delivery or viewing, not copied into Pepe Pay’ database, logs or error reports. An application freshness limit does not promise that the issuer still accepts a code. Telegram sign-in does not create a password; where an account has one, it is stored only as a bcrypt hash.

Telegram and in-app code notices are enabled by default and can be disabled separately in Profile. The bot sends the issuer message to your own private chat under a spoiler. The app first shows a notice without the code; you choose whether to reveal it. Email delivery is currently marked Soon and cannot collect or send to an address. When released, it will require confirmation of a separate notification address and explicit opt-in. Changing that address will revoke confirmation and disable delivery; it will not change a staff account’s sign-in email.

Support messages you choose to send are separate from this protected reveal: a staff account can read them. App conversation text is stored so you can read the history and receive answers there. Do not put card details, one-time codes, passwords or wallet secrets in either support chat.

• To provide the service: identifying your account, keeping your balance and card records accurate, forwarding your card requests to the provider, and showing your history — including, for a shared card, the card activity a team grant makes visible.
• To operate team access and its record: storing the team, its members, invitation links, the card grants an owner creates and a non-secret activity record, so the service can run invitations, check on every read whether a member may still see or use a shared card, and show the owner which member credential or 3DS-code opens happened.
• To notify you about management fees: showing due/overdue notices in the app and making a best-effort Telegram reminder. Reminder records contain the card/period identifiers, due amount, delivery state and message ID, not card credentials or a copy of the message text. A delivery failure or uncertain send does not guarantee another attempt; the in-app notice remains available.
• To show card details on request: fetching the card’s details and the issuer’s one-time 3-D Secure messages from the provider and displaying them to the card’s owner, or to a member with an active team grant, in the Mini App for a short window, without keeping them.
• To deliver one-time card codes to the card owner: matching the provider notification to the owner’s active card and fetching the corresponding issuer message for the owner’s chosen channels. Automatic delivery is never sent to a team member’s chat. Settings are rechecked before an external send. A failed or uncertain send is not automatically repeated, so delivery is not guaranteed.
• To keep it working: detecting duplicate requests, syncing card statuses and transactions, and keeping sessions valid.
• For security and abuse prevention: limiting request rates, investigating fraud or misuse, and enforcing the acceptable use policy.
• To meet legal obligations that apply to the operator, including record-keeping and responding to lawful requests.
• To answer you when you ask a question through the published contact channel.

Pepe Pay does not run third-party advertising, does not sell personal data, and does not build third-party marketing profiles. Optional first-touch campaign attribution is the only acquisition measurement and is described in section 10; it records a registered campaign code and Telegram identity only after opt-in.

• The card provider. Card requests, identity data you supply when the provider asks for verification, and the card operations you trigger are passed to the provider so it can issue and operate the card and report its status back. For direct deposit invoices, Spendge also receives the payer name you provide, the amount and invoice reference, and processes the blockchain payment and its receiving address.
• Other Pepe Pay accounts in a team. If you own a card and share it with a team, the team’s members can read that card’s balance, status, spending limit, amount spent, masked number and expiry, and its payment, refund and provider-fee activity. They can fetch its credentials and 3-D Secure codes inside Pepe Pay while the grant is active. They do not receive your wallet records, your other cards, your automatic 3-D Secure notifications or your sign-in. Your Telegram name, username and numeric ID are shown to the other members of a team you join. The team owner can read the team’s activity record, including member credential and 3DS-code opens; members cannot. Anyone holding an invitation link can preview the team name, the owner’s public first name and member and card counts before signing in; the link is single-use and expires. Removing a member or a card grant ends future access through that team only; another team may still grant access, and copies already made cannot be recalled.
• Telegram and the support team. Telegram processes bot conversations. Support questions written in the app or to the bot are stored in the operator support inbox together with your account; a staff account reads and answers them from the web workspace. Answers appear in your private app conversation and, when the account is linked, are delivered to your own Telegram chat. Neither flow requires a conversation with a personal account. Separately, if Telegram code delivery is enabled for a card you own, the bot sends that card’s 3-D Secure messages directly to your own chat, not to the support inbox. Telegram processes and retains those messages. A spoiler is visual concealment, not end-to-end encryption.
• Email delivery providers. If you confirm an address and enable email code delivery, the configured mail transport and your mailbox provider process your address and the issuer message. Transport to the mail server uses verified TLS; this is not a promise of end-to-end encrypted email.
• Infrastructure providers. The database, hosting and error-monitoring services that run and protect the service process data on the operator’s instructions.
• Authorities, where the law requires it. If a competent authority makes a lawful request, data is disclosed to the extent required.

Personal data is not sold, and it is not shared for third-party advertising.

Pepe Pay runs on hosted infrastructure, and the card provider processes card data and any verification data supplied to it in its own locations.

The operator’s verified details, including the countries involved, are not published. No transfer framework is claimed here: this section is not filled with a standard clause, and the contact page records which details remain unpublished.

• Account data is kept while your account is open, because the balance, cards and history need it.
• Team records — the team name, members, invitations and card grants — are kept while the team exists. Removing a member or revoking a card deletes that membership or grant, revoking an invitation marks it revoked, and deleting a team deletes its memberships, invitations and grants. The non-secret team activity record is append-only: it remains after a team, card or account is deleted so the operator can review what happened, and it contains no card number, CVV, password, code or invitation token. The owner can read it while the team exists. The shared card, its balance and its transactions remain with the card owner.
• Sessions expire and are then no longer usable; expired sessions are not needed to operate your account.
• Money records (deposits, withdrawals, transactions, fees) are kept after an account closes where record-keeping obligations or dispute handling require it.
• Delivered bot/support routing records are removed after 14 days. Pending or failed deliveries remain for recovery. Messages held inside Telegram follow Telegram’s retention and deletion rules.
• 3-D Secure delivery metadata is removed seven days after its expiry. Card-code text is never stored in these records. Notification preferences and the confirmed email remain until you change or remove them, or the account is deleted subject to the other retention obligations. Email confirmation challenges expire after ten minutes; expired hashes are cleared by the hourly cleanup or replaced by a new challenge.
• Closing a private code window clears the app’s transient display; it does not delete copies already sent through Telegram or email. Those copies follow the receiving services’ retention and deletion rules.
• Delivered in-app support questions and staff answers are removed after 30 days from their last record update. Undelivered, pending or failed questions remain for recovery instead of being silently deleted before support receives them.
• Technical logs are short-lived operational records, not an archive of your activity.
• Optional campaign attribution: 180 days from first touch, or until you turn attribution off (deleted immediately). Consent/opt-out control record: retained while attribution is offered/disabled for your identity so the choice is honored. Wallet/card/transaction records follow their existing financial-retention rules and are not part of attribution reports beyond aggregate stage counts.

If you ask for deletion, Pepe Pay removes what it can and tells you what has to be retained and why. Data held by the card provider is deleted according to the provider’s policy and cannot be erased by Pepe Pay.

• Ask for a copy of the data stored about you, or ask for a correction.
• Ask for deletion. Note that closing an account and deleting every record can differ: some records must be kept, as described in section 6.
• Change each 3-D Secure delivery channel in Profile or remove your notification email. This stops delivery not yet attempted; it cannot recall a message already sent to Telegram or a mailbox.
• Withdraw your balance first if you intend to close the account, where an external payout route is available; deletion is not a substitute for the withdrawal process. External crypto payouts are not available in the current build because no payout route can send to an external address.
• If you are a team member, you can leave the team, which ends access through it immediately. The card owner decides whether to keep sharing a card and can revoke a grant at any time. Asking Pepe Pay to delete your data does not by itself revoke another person’s card or recall credentials already copied outside Pepe Pay.
• Depending on where you live, you may have further rights (for example, to object to processing or to complain to a supervisory authority). Requests go through the channel on the contact page, and we may need to verify that the account is yours before acting.

• The service is served over HTTPS only.
• Sign-in uses signed tokens with refresh rotation, and password hashes (where a password exists) use bcrypt.
• Secrets and provider credentials live in server configuration.
• Card data kept by Pepe Pay is masked, so a full card number is never displayed from Pepe Pay’ own records. Card details are fetched only for an explicit private-view request by the card owner or by a member with an active team grant, and that access is checked again before the response is returned. Issuer 3-D Secure messages can also be fetched for the owner’s delivery channels or read by an active member in the app; their text is not persisted by Pepe Pay.
• Team access, membership and card grants are checked on every card read. A revoked grant cannot be used to obtain a late credential or code response.
• API endpoints are restricted to authenticated sessions, with role-based access for administrative operations.

No system is perfectly secure. If you believe you have found a security issue, report it through the contact page instead of testing it against other people’s accounts.

The service is not intended for anyone under 18, and accounts that breach this are closed. Pepe Pay does not knowingly keep data about children; if you believe a child has used the service, report it through the contact page.

Optional campaign attribution. Attribution is optional and off by default; it is never required to use Pepe Pay. If you enable it in your profile, we may record which registered campaign link brought you to the bot or Mini App, using your Telegram account identity and the campaign code from the signed Telegram launch or the bot’s own message. We do not collect IP addresses, device fingerprints, raw Telegram initData, third-party tracker identifiers, card numbers, CVVs, one-time codes, merchant descriptions or purchase contents for attribution. The first-touch campaign association is kept for 180 days; it is not rewritten, and turning attribution off deletes it immediately. We retain only a small granted/revoked choice record so an opt-out is respected. Campaign starts before you opt in are not measured or reconstructed. Admin reports show aggregated counts for consenting users only and never list individual profiles. After an attributed visit we also retain the first verified app sign-in timestamp to distinguish a bot visit from an actual app sign-in.

Необязательная атрибуция кампании. Атрибуция необязательна и выключена по умолчанию; она не требуется для использования Pepe Pay. Если вы включите её в профиле, мы можем сохранить, по какой зарегистрированной ссылке кампании вы пришли в бот или мини-приложение, используя идентификатор вашего Telegram-аккаунта и код кампании из подписанных данных запуска Telegram или сообщения самого бота. Для атрибуции мы не собираем IP-адреса, отпечатки устройств, необработанные initData Telegram, идентификаторы сторонних трекеров, номера карт, CVV, одноразовые коды, описания покупок у продавцов или содержимое покупок. Первичная связь с кампанией не перезаписывается и хранится 180 дней; при отключении атрибуции она удаляется сразу. Мы оставляем только небольшую запись о вашем выборе (согласие/отзыв), чтобы соблюдать отказ. Запуски до вашего согласия не измеряются и не восстанавливаются. Отчёты администраторов показывают только агрегированные счётчики по согласившимся пользователям и никогда не содержат списки профилей. После перехода по кампании мы также сохраняем время первого подтверждённого входа в приложение, чтобы не считать посещение бота входом в приложение.

This policy is versioned and dated at the top of the page. Material changes are announced in the Telegram bot before they take effect. When verified operator details are published, this policy is updated in the same step.

Privacy questions, data requests and security reports all go through the published support conversation described on the contact page, or through the app support chat. No dedicated privacy mailbox is published. The operator legal details that remain unpublished are recorded separately on the contact page.