Business Logic Vulnerability: When Multiple Accounts Can Share the Same Payout Details

Business logic vulnerabilities are often overlooked because they do not always involve classic security issues such as SQL Injection, Cross-Site Scripting, or Remote Code Execution. Instead, they arise when an application's workflow allows actions that conflict with the intended business rules.

One interesting scenario involves payout settings.

The Scenario

Imagine a platform that allows users to receive payments through bank accounts, gift cards, cryptocurrency wallets, or other payout methods.

A user can navigate to their profile and configure payout information that will be used to receive future rewards or payments.

Now consider the following workflow:

1. User A registers an account.
2. User A adds a bank account and payout email.
3. The platform saves the information successfully.
4. User B registers a completely different account.
5. User B enters the exact same payout information.
6. The platform accepts the details without any validation or review.

As a result, multiple accounts become associated with the same payout destination.

Why Is This Interesting?

At first glance, this may appear harmless. However, from a business logic perspective, payout information is often treated as an identifier that links financial transactions to a specific user.

Allowing the same payout destination to be associated with multiple accounts can create challenges for fraud detection, abuse prevention, and account attribution.

The issue is not necessarily the duplicate data itself. The real concern is how that data may be used by other business processes within the application.

Potential Risks

Multi-Account Abuse

Many platforms attempt to limit abuse by restricting rewards, promotions, referrals, or bonuses to one user.

If the same payout destination can be reused indefinitely, a single individual may create multiple accounts while still directing all payments to a single destination.

Referral Program Abuse

Referral systems frequently assume that each participant represents a unique individual.

When payout destinations are not validated, an attacker may create multiple accounts and funnel rewards to the same financial endpoint.

Fraud Investigation Challenges

Security and fraud teams often rely on payout information to identify relationships between accounts.

If duplicate payout information is allowed without monitoring or review, suspicious activity may become harder to investigate.

Ban Evasion

Platforms sometimes ban accounts involved in abuse or policy violations.

If payout information is not used as part of anti-abuse controls, a banned user may create additional accounts while continuing to use the same payout destination.

How Security Researchers Can Test This

When assessing payout systems, researchers can examine the following:

• Can multiple accounts register the same bank account?
• Can multiple accounts use the same payout email address?
• Are duplicate cryptocurrency wallet addresses accepted?
• Is there any verification process for payout ownership?
• Does the application generate warnings when duplicates are detected?
• Are duplicate payout destinations reviewed by fraud systems?

The objective is not merely to identify duplicate data acceptance but to understand how the platform's business processes interact with that data.

Example Test Flow

1. Create Account A.
2. Add a payout destination.
3. Create Account B.
4. Add the same payout destination.
5. Observe whether the platform:

• Rejects the entry.
• Generates a warning.
• Requires additional verification.
• Accepts the data silently.

Documenting these behaviors can help identify weaknesses in fraud prevention and account attribution mechanisms.

Security Recommendations

Organizations can reduce risk by implementing several controls:

Server-Side Uniqueness Checks

Validate whether a payout destination already exists before saving it to another account.