## [CONTRACT-23] Implement pay_per_use_to for Third-Party Merchant Payments

[orunganiekan]

• Points: 200
• Labels: contract, pay-per-use, token, extensibility

Background

pay_per_use in lib.rs always routes payment to sub.merchant — the merchant stored in the subscription at subscribe time. This means a subscriber cannot make a one-off payment to a different merchant using the same subscription allowance, even if both are whitelisted. Use cases include: tipping a different creator, paying a marketplace fee to a platform address, or routing a single transaction to a sub-merchant in a marketplace context. The contract already tracks the subscription token and validates allowance — the routing logic is the only missing piece.

Task

Add pay_per_use_to(env: Env, user: Address, amount: i128, recipient: Address) as a public function. It follows the same flow as pay_per_use but transfers to recipient instead of sub.merchant. If whitelist::is_whitelist_enabled, verify recipient is whitelisted. Apply the protocol fee (split between fee collector and net to recipient). Record spend against the user's daily limit. Emit a pay_per_use event with recipient in place of sub.merchant. Do NOT update MerchantRevenue for sub.merchant — only update it for recipient.

Key Files

• contract/src/lib.rs — add pay_per_use_to; factor shared pay-per-use logic into pay_per_use_inner(env, user, amount, recipient) used by both functions
• contract/src/fee.rs — add transfer_pay_per_use(env, user, sub_token, amount, recipient) -> i128 mirroring the subscription charge transfer but accepting an explicit recipient and token
• contract/src/test.rs — test: pay_per_use_to transfers to the specified recipient, not sub.merchant; test: whitelist-enabled contract rejects non-whitelisted recipient; test: daily limit applies to pay_per_use_to spending

Edge Cases

• The subscription must be active and not paused (same checks as pay_per_use)
• sub.token is used for the transfer — the recipient cannot specify a different token
• pay_per_use_to with recipient == sub.merchant must behave identically to pay_per_use (no special-casing needed, but confirm in a test)
• Daily limit tracks total spend across both pay_per_use and pay_per_use_to calls

Acceptance Criteria

• pay_per_use_inner is a private function used by both pay_per_use and pay_per_use_to
• pay_per_use_to requires user.require_auth() and ensure_contract_not_paused
• Whitelist check applied to recipient when whitelist is enabled
• MerchantRevenue incremented for recipient, not sub.merchant
• Daily limit enforced across both pay-per-use variants
• Test: payment routed to recipient with correct net amount after fee
• cargo test passes with no regressions

[otsimaofficial]

@otsimaofficial has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hey maintainer i am familiar with this task kindly assign issue to me.
Thank you

ℹ️ Repo Maintainers: To accept this application, review their application or assign @otsimaofficial to this issue.

[drips-wave]

Congratulations, @otsimaofficial! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 30, 2026.

🧑‍💻 @otsimaofficial: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊