AffiliPartnerCS / Security & Privacy
Protect payout actions, credentials, partner data, and financial history.
Layered server-side checks separate user permissions, organization access, partner lifecycle, request intent, and financial state. Each control protects a different part of the relationship.
WooCommerce partner-commerce software · Customer Reference 1.3.9
Financial authority
Automation does not mean unrestricted payment permission.
PayPal and Stripe stay reviewed
An authorized finance user reviews the frozen recipient and terms before each native submission. Schedules, preference changes, page views, and provider callbacks cannot independently authorize a new payment.
Store Credit has an explicit policy
With compatible credit services, choose manual approval or explicitly enabled automatic settlement. Beneficiary, amount, currency, tax, lifecycle, integrity, and duplicate checks still apply.
Final earnings stay final
Late refunds, disputes, chargebacks, or provider reversals do not silently reopen paid commission or manufacture new partner debt. Customer refunds remain WooCommerce decisions.
Recover the record; do not repeat the value.
A known successful provider payment or credit issuance is reconciled against its saved reference. Local ledger recovery finishes accounting without sending or issuing a second time. Unknown outcomes block another send.
Separate the consequential permissions
- View
Read the records allowed for the actor.
- Review
Check the calculation and eligibility.
- Authorize
Use the required payment authority.
- Reconcile
Attach the confirmed result to the existing attempt.
Access and request checks
A familiar link is not authorization.
Staff capabilities govern program, partner, finance, payout, settings, integration, secret, export, audit, maintenance, and message access. Partner membership determines whose records a user can see. A partner’s Finance seat is not the merchant’s Finance role and does not grant WordPress administration.
The server checks submitted actions, relevant record ownership, lifecycle, and current state. State-changing forms include time-limited request protection. Financial operations add duplicate-intent and concurrency controls; an otherwise valid form cannot bypass a hold or create another payment simply by being submitted twice.
Input is validated for expected type, length, permitted choice, record context, and currency/amount meaning. Output is escaped for its destination, and supplied form text is not executable PHP. A record number or hidden button is not accepted as the security boundary.
Member verification
Short-lived proof. A separate protected pricing session.
A trusted partner server signs login state and the exact secure destination using HMAC-SHA256. The message is valid for no more than five minutes, intended for one use, and checked against the authorized store origin including host and effective port. Modified, expired, replayed, unsigned, or incorrectly signed requests receive no protected pricing.
Accepted verification creates a separate secure random pricing token. Server-side lookup uses a hash rather than the raw browser token; the cookie requires secure transport, restricts ordinary script access, and expires explicitly. The pricing session defaults to 30 days, with merchant/partner configuration determining the effective duration.
Rotating the signing key controls new messages; existing sessions follow their own lifetime and relationship checks. Affiliate referral cookies are different: they hold public marketing context, not signed membership proof or account credentials.
Credential protection
Keep secrets out of routine work.
Relevant trust secrets, provider credentials, and protected session information use authenticated AES-256-GCM encryption at rest, tied to WordPress secret material and deployment context. Authorized reveal and rotation are explicit actions; supported provider credentials may be supplied through protected deployment configuration.
Ordinary dashboards, partner views, exports, public scripts, and standard reporting do not expose those values. Welcome and rotation emails do not carry signing secrets. Protect configuration and encrypted data together in backups; changes to secret material or deployment may require re-entering affected credentials.
Remote destinations are constrained with appropriate secure-address validation, timeout/size limits, and redirect handling. Merchant-selected receivers remain services you must trust and manage. Encryption does not replace securing hosting, administrators, or the runtime.
Community privacy
Preserve the distinction between connection modes.
Self-hosted Discourse and XenForo
The verification handoff supplies what is needed to prove login state without transferring the member’s password, username, private messages, or profile. The store does not need a copy of the community member database.
Managed Discourse
Mandatory identity fields briefly pass through the signed callback and are discarded after verification. Exclude those callbacks from server, proxy, CDN, security, analytics, and session-replay capture too; plugin disposal cannot remove another service’s copy.
Partner and customer privacy
Useful financial evidence without customer exposure.
Partners use safe commission references rather than customer names, billing emails, shipping addresses, private order numbers, or merchant order-edit links. One organization’s access does not unlock another organization’s data.
Applications and partner profiles legitimately contain supplied contacts. Payment profiles may need an email, handle, or mailing address; messages contain what authors submit. These are access-controlled records, not anonymous data. Stripe hosts banking and identity information, and the hosted tax provider retains completed forms and tax identifiers.
| Enabled destination | Information involved |
|---|---|
| Community verification | Login-state/destination information; managed Discourse also has the transient identity handling described above. |
| PayPal / Stripe | Reviewed payment, recipient/connected-account readiness, and status-verification information. |
| Hosted tax provider | Pseudonymous partner reference, year, compensation context, and protected return information. |
| Merchant event receiver | Selected partner, application, order, commission, payout, or operational events. |
| Optional QR renderer | Generated link, image size, and normal browser connection information. |
| WordPress mail transport | Recipient address and rendered notification. |
| Local Store Credit integration | Verified beneficiary, payout/credit references, currency, amount, and settlement breakdown. |
Retention and accountability
Erase eligible personal data without silently destroying financial history.
WordPress personal-data export and erasure tools scope requests to the matching applicant, owner, or team member. Eligible contact/access/invitation/request/message information can be erased or detached. Protected financial, tax, fraud, conversion, security, and audit records remain for merchant retention review; a team member’s request does not erase the organization’s whole ledger.
Audit records identify material events, actor, record, time, severity, and bounded context. They remain separate from opt-in diagnostic logging. This supports accountability; it is not a claim of an immutable database against someone with full database access.
Deactivation preserves business records. Safe maintenance, sample removal, Factory Reset, and uninstall deletion are distinct operations. The merchant sets applicable retention and downstream-provider policies. These controls support responsible operation without promising immunity from unsafe hosting, stolen administrator accounts, or third-party code.
Your programs. Your partners.
One connected way to manage them.
Choose the license package that fits your sites. Existing AffiliPartnerCS packages and purchase terms remain on the pricing page.