Repository navigation
Technical Payments
Audience: developers and advanced administrators. Baseline reviewed: 2026-10-29. This page describes implementation behavior, not provider-account or financial advice.
| Outcome | Evidence |
|---|---|
| Provider accepted/settled a payment | Verified provider transaction/invoice state |
| Wallet was credited | Committed local ledger/idempotency record |
| Requested access was fulfilled | Rental, subscription renewal or live-event entitlement |
A browser success message, approved agreement or funded wallet does not alone prove all three outcomes.
YPTWallet::processPaymentOnce() serializes provider payment claims using a database lock and transaction, then records processed identifiers. Provider retries, browser return and polling can converge on the same purchase; duplicate-delivery handling is essential.
YPTWallet::runPaymentStep() uses a savepoint inside the active payment transaction. A failed rental/renewal can be undone while legitimate wallet funding remains. A database error has different handling from an unsupported/unrelated event or a fulfillment result of false.
Read the wallet reference and actual provider implementation before changing transaction nesting, retry responses or idempotency identifiers.
| Integration | Current behavior to trace |
|---|---|
| StripeYPT | Single-payment card confirmation happens in the browser; charge.succeeded delivery processes credit. Duplicate handling considers provider timestamps and local pending credit. Refund state is re-read. |
| PayPalYPT | Local checkout records are reconciled by return, webhook/IPN and polling. Provider state is re-read; agreement approval alone grants nothing. |
| BTCPayments | Marketplace-mediated invoices, polling reconciliation and callback delivery. The marketplace bridge is a separate service/repository. |
| AuthorizeNet | Pending-payment records, verified transaction processing, recurring plans and periodic reconciliation. |
| RazorPayYPT | Provider verification and wallet/fulfillment processing through its specific webhook path. |
Provider credentials, webhook registration and sandbox/production selection belong to each site's/provider configuration. They are not interchangeable across installations. Do not create/delete webhooks as an incidental side effect of a purchase path unless that is the verified supported contract.
Subscription, FansSubscriptions, PayPerView, PayPerViewLive, Gift and DiskUploadQuota maintain distinct plan/entitlement workflows. Confirm the selected product, server-side amount, payer, recipient, validity window and completion state. A plan identifier is meaningful only in its owning plugin/version.
View counts can be financially relevant when MonetizeUsers is enabled. Inspect actual reward consumers before treating statistics mutations as cosmetic.
Correlate safe provider transaction/invoice identifiers with the local checkout, wallet log and fulfillment record. Distinguish an unpaid/confirming/expired purchase, a delivery retry, a completed credit and a failed fulfillment step. Inspect transaction rollback and HTTP/provider retry behavior before manually replaying events.
Use provider sandboxes or an explicitly authorized local testnet workflow for end-to-end checks. No real purchases, refunds, webhook deliveries or provider-account changes were performed to create this documentation.
