PayStar API Documentation
  1. FEATURES | EN
  • MERCHANT
    • PRODUCTS | EN
    • ПРОДУКТЫ | RU
    • Untitled Doc
    • FEATURES | EN
      • Deposits & Payouts
      • Issues (Tickets)
      • Secure data (One-time secret)
      • Summary Report
      • Payment Analytics
      • Payment Form Analytics
      • Unified audit log
      • Export reports
      • Black list
      • Routing & Cascading
      • Limits
      • Commissions
      • Team
      • My Account
      • PayStar in 100 Questions
    • ВОЗМОЖНОСТИ | RU
      • Депозиты и выплаты
      • Issues (Задачи)
      • Защищённые данные (One-time secret)
      • Сводный отчёт
      • Аналитика по платежам
      • Единый журнал событий
      • Аналитика платёжной формы
      • Экспорт отчётов
      • Черный список
      • Мавршрутизация и Каскады
      • Лимиты
      • Комиссии
      • Команда
      • Мой аккаунт
      • PayStar в 100 вопросах
    • API DOC | EN
      • Introduction
      • Glossary
      • Authorization key
      • Sandbox
      • Additional fields
      • Currencies
      • Bank names
      • Telecom operators
      • Callbacks
      • Error descriptions
      • Tech FAQ
      • Events
      • Payment history v2
        • Payment history - backward compatibility (legacy `X.Y.Z.W`)
      • Integratins
        • Stripe
        • Inwizo
        • 2Checkout
        • Adyen
        • AffiniPay
        • Alikassa
        • AlliancePay
        • Amazon Pay
        • AnyMoney
        • AstroPay
        • Aureavia
        • AurisMyChanger
        • Authorize.Net
        • Avatarix
      • Balance H2H
      • Deposit H2H - Card & P2P
      • Deposit H2H - Token
      • Deposit H2C - Card
      • Deposit status H2H - PayStar ID
      • Deposit status H2H - Merch ID
      • Payout H2H
      • Payout status H2H - PayStar ID
      • Payout status H2H - Merch ID
  • AGENT (REFERRAL)
  1. FEATURES | EN

Black list

The Black list section is a simple tool for hard-blocking suspicious requisites (card / email / IP / phone / PayeerIdentifier). It helps you quickly stop repeated problematic attempts, reduce fraud risk, and unload support — before traffic goes into routing and then to providers.
image.png

1) When you should use Black list#

Black list is useful when you are sure that a specific requisite must not be allowed:
fraudulent requisites (repeated attempts that hurt conversion and provider limits);
test runs / brute-force attempts;
users/requisites flagged during investigations (support case / risk case);
prevention of repeated chargeback patterns.
Important: Black list is a permanent block — it remains active until the entry is updated or deleted.

2) By Merch vs By Pipeline — how to choose the scope#

When you add a new entry, you choose a tab:
By Merch — the block is applied for the merchant (broader scope).
By Pipeline — the block works only within the selected pipeline (more targeted, lower risk of affecting other routes).
image.png

3) What types of requisites can be blocked#

TypeWhat is blockedExample
CardCard number4111111111111111
EmailPayer emailuser@mail.com
IPIP address203.0.113.10
PhonePhone number+447700900123
PayeerIdentifierPayer identifier12345678980
image.png

4) How to add an entry to Black list#

1.
Open Black list.
2.
Click + Add new.
3.
Choose By Merch or By Pipeline.
4.
Select Merchant or Pipeline.
5.
Select Type.
6.
Enter the value in Requisites.
7.
(Optional) fill Description — a comment/reason.
8.
Click Add.

What the fields mean#

Merchant / Pipeline — where exactly the blocking rule is applied.
Type — the requisite type (card/email/IP/phone/identifier).
Requisites — the exact value to be blocked.
Description — reason/context (for example: fraud, chargeback, test user, case #1234).

5) Search and filters#

Filters available at the top:
Created
Merchant
Pipeline
Type
Requisites
Description
The Clear Filters button resets all filters.
image.png

6) How to update an entry (Update)#

1.
In the row, open the ⋮ menu.
2.
Click Update.
3.
Apply changes and click Save.

7) Temporary blocking: why it’s better handled via routing#

If you need to temporarily restrict a user, for example:
“more than N failed attempts within 24 hours”,
“more than N attempts from one IP per hour”,
“suspicious behavior — send to a separate scenario”,
it’s better to implement this in routing, because:
you can define a threshold and time window,
the restriction can be lifted automatically when the window ends,
you can choose a soft response (not always a hard block): lower priority, another scenario, another PSP, etc.
Useful: routing logic example (video)
https://youtu.be/9BhqEqoIRAM

8) Business best practices: how not to hurt conversion#

Start with a targeted approach: By Pipeline → expand to By Merch only if needed.
Always record the reason and source in Description (support/risk case).
Use routing for temporary limits, not “forever” Black list entries.
Review the list regularly:
quick review — weekly,
cleanup of outdated/duplicates — monthly/quarterly.

9) FAQ#

1. What happens if a payment matches the Black list?
The attempt will be blocked by the blacklist rule and will not proceed further.
2. Which should I choose: By Merch or By Pipeline?
By Merch — broader, for the merchant.
By Pipeline — targeted, for a specific flow.
3. Can Black list be used as a “whitelist”?
No. It’s a deny tool. Use routing for exceptions/prioritization.
4. Can I set a TTL (entry lifetime)?
In Black list, entries remain active until updated or deleted. For temporary rules, use routing.
5. What should I put in Description?
Short and audit-friendly: fraud, chargeback, bonus abuse, test, case #1234, provider request.
6. What if we blocked a legitimate customer (false positive)?
Find the entry, adjust the scope (often switching to By Pipeline helps), then update/delete it and add a note explaining why the block was removed.
Previous
Export reports
Next
Routing & Cascading
Built with