A partner who keeps sending qualified customers should not wait for a spreadsheet review to earn better terms. Manual upgrades create delays, inconsistent decisions, and payout questions later.
Rewardful partner upgrades work best when you treat them as a controlled revenue workflow. Rewardful can track referrals and commission activity, while your rules engine decides when a partner has earned a new tier.
Set the policy first. Then connect events, test the record flow, and promote only partners whose data you can verify.
Automate Rewardful partner upgrades with a clear rule
Do not start with a webhook. Start with the rule that makes someone eligible.
A tier upgrade needs a measurable trigger, a review period, and an effective date. Without those three parts, your automation will promote the wrong partner or create a commission dispute.
Define the performance threshold
Use conditions your finance and partnership teams can reproduce from stored records. Referral clicks alone are not enough. A click shows interest. A paid and attributed customer shows commercial value.
Your policy might require all of the following:
- A minimum number of active referred customers.
- A minimum amount of collected referral revenue.
- A defined measurement window, such as the prior 60 or 90 days.
- No open fraud, refund, chargeback, or compliance review.
- A partner account that is active and approved.
For example, you could upgrade a partner after 10 active referrals and $2,000 in collected referral revenue during the previous 60 days. State whether “collected” means paid invoices only, or paid invoices less refunds and credits.
Write the rule in plain language. A partner should be able to read it and understand why they did or did not qualify.
Separate customer changes from partner upgrades
Rewardful already adjusts commissions when a referred customer’s subscription changes. Its automated commission adjustment process accounts for upgrades, downgrades, cancellations, and refunds tied to affiliate sales.
That is different from a partner tier upgrade.
A customer moving from a $49 plan to a $99 plan changes the value of a sale. A partner moving from a 20% rate to a 25% rate changes the terms of your partner agreement. Keep those decisions separate in your data model.
A paid invoice can increase a partner’s eligibility score. It should not change the partner’s tier until your full policy check passes.
Build a source of truth before changing rates
Your automation needs one accepted record for each partner. Do not calculate tier status from browser reports, copied totals, or disconnected spreadsheets.
Store the partner identifier, campaign, current commission terms, eligibility window, revenue events, refund adjustments, decision status, and effective date in your internal system.
Use attributable revenue, not headline revenue
A referred subscription is only useful for a tier calculation when attribution is clear. Keep the Rewardful affiliate or partner ID tied to the referral, customer, and revenue event where your workflow supports it.
Rewardful publishes webhook events for referral states, including referral.created, referral.lead, and referral.converted, plus commission and payout events. Review the Rewardful event type list before you map your workflow.
For each qualifying event, store:
- The event type and delivery timestamp.
- The referral, commission, and partner identifiers available in the payload.
- The amount, currency, and status used for the calculation.
- The source event ID or a stable deduplication key.
- The workflow run ID and the rule version used.
This gives RevOps a record they can inspect when a partner asks why their status changed.
Set the commission policy before promotion
Decide if the new rate applies only to future referrals, future invoices from existing referrals, or a defined group of referred customers after the upgrade date.
Prospective terms are easier to audit. Retroactive changes can be fair, but they increase calculation work and payout risk. Do not make a retroactive adjustment without a written policy and finance approval.
Rewardful calculates recurring affiliate commissions from Stripe activity and adjusts records when billing changes occur. Its explanation of how affiliate commissions are calculated and adjusted is useful for checking how upgrades, refunds, and renewals affect your expected totals.
Connect Rewardful events to your decision workflow
Rewardful webhooks are the event source. Your automation service is the decision layer. Keep those jobs separate.
Rewardful sends webhook notifications when activity happens in your account. The platform’s webhook setup guidance covers adding an endpoint for those notifications.
Receive events without making instant decisions
Accept the event, validate it, store it, then place it in a queue. Do not change a partner’s tier inside the first request handler.
Webhook deliveries can arrive late. A retry can happen. Events can also arrive in an order that does not match the order of the underlying customer activity.
Your endpoint should:
- Accept only HTTPS requests from the configured source.
- Check the authentication or verification method available for your integration.
- Store the original payload before changing any internal record.
- Return a success response only after durable storage succeeds.
- Send the event to a worker that evaluates eligibility.
Rewardful sends webhook data as JSON. Its webhook request reference shows the event data structure your team needs to map and retain.
Handle duplicates and delayed adjustments
Use idempotency rules. Process each source event once, even if your endpoint receives it twice.
If the payload includes a stable event identifier, store it as unique. If it does not, build a fingerprint from the event type, object ID, timestamp, and relevant amount. Keep the raw payload hash as supporting evidence.
Do not add revenue twice because a commission event is retried. Do not remove eligibility permanently because a refund update arrived before the related commission record.
Recalculate a partner’s status from your ledger when a relevant event arrives. The ledger should show positive revenue events, refunds, voids, and manual adjustments as separate lines. Never overwrite history to make the current total look clean.
Count accepted upgrade records, not webhook deliveries. A workflow that handles 500 events but promotes three incorrect partners has failed.
Apply the upgrade through a controlled action
Rewardful documents referral, commission, payout, API, and webhook automation. Its public documentation does not describe a universal native engine that automatically changes a partner tier after a performance threshold.
Build the promotion action around the commission structure and account options you have approved. Keep a manual approval step during the first rollout.
Create an upgrade decision record
Your worker should produce one decision record per evaluation period. Include the partner ID, rule version, metric values, decision, effective date, reviewer, and the intended commission change.
Use clear statuses:
| Status | Meaning | Next action |
|---|---|---|
| Pending | Events are still inside the holding period. | Wait for the next evaluation. |
| Eligible | The partner meets every condition. | Send for approval or approved action. |
| Upgraded | New terms are active from the recorded date. | Notify the partner and monitor. |
| Blocked | A refund, fraud review, or missing record prevents action. | Route to an owner. |
A hold period protects your program from promoting a partner based on revenue that later disappears. Your period should match the refund and payment-risk pattern of your SaaS business.
Make the external change once
After approval, apply the change through the Rewardful configuration or supported API path your account uses. First read the current partner and commission setup. Then write the approved change. Finally, read the record again and compare it with the intended outcome.
Store a before-and-after snapshot. Include the operator or service identity, timestamp, change request ID, and response received from the connected system.
Do not run a blind update after every qualifying event. A partner who crosses the threshold on Monday should not receive another rate change on Tuesday because a duplicate event reached the queue.
Test refunds, repeats, and rollback paths
Run a controlled test before you enable live Rewardful partner upgrades. Use a Stripe test environment where your account setup permits it. If that is not available, use a low-risk internal referral and do not pay a live commission until the records reconcile.
Test the cases that cause payout disputes
Run each case through the same endpoint, queue, ledger, decision logic, and approval process you plan to use in production.
Test a clean qualifying referral. Test the same event twice. Test a commission update after the initial event. Test a full refund after the partner qualifies. Test a partial refund. Test a delayed event that arrives after the evaluation window closes.
Also test an attribution conflict. A visitor may have clicked one partner’s link, returned later through another link, or converted after the attribution period expired. Do not classify every missing commission as a system defect.
Keep a usable rollback procedure
A rollback is not deleting an upgrade record. It is creating a documented reversal that preserves the original decision.
Your rollback procedure should identify the reason, the affected partner, the previous terms, the corrected terms, the effective date, and the person who approved the reversal. Notify finance before the next payout run if the change affects payable commissions.
Keep audit logs for raw events, calculated metrics, approvals, system actions, failures, and reversals. When something looks wrong, your team needs to reproduce the decision without guessing.
Communicate the criteria and monitor the program
Partners should not discover a new tier through a changed payout amount. Publish the criteria in your program terms, partner guide, or onboarding message.
State the measurement period, qualifying revenue definition, exclusions, review timing, new commission terms, and whether terms apply prospectively. Explain how refunds, chargebacks, cancellations, and delayed payments affect status.
Set a weekly reconciliation between your internal upgrade ledger, Rewardful commission records, and Stripe billing data. Review exception queues for duplicate events, missing identifiers, rate changes without approval, and partners who crossed a threshold but remain pending.
Assign each exception to an owner and follow-up date. A visible blocked record is better than a silent failed upgrade.
Put the Upgrade Workflow Into Production
Automated upgrades work when the policy, revenue records, and commission action all agree. Start with one tier, one qualification rule, and a small group of approved partners.
Keep the first rollout reversible. Review every decision, compare it with Rewardful and Stripe records, and expand only after the team accepts the results.
If you need help mapping events, approval rules, and the audit path before launch, Book A Call.
