Rewardful vs Tapfiliate Migration Guide for Stripe SaaS
Plan a Rewardful vs Tapfiliate migration for Stripe SaaS with data exports, affiliate links, Stripe event tests, payout checks, and a safe cutover.
What Should You Compare Before Choosing?
A Rewardful to Tapfiliate migration is a tracking and records project, not a simple account switch. The safest plan exports the old system before cancellation, maps affiliates and links, rebuilds the first conversion path, tests Stripe lifecycle events, settles old balances, and keeps a rollback window.
The important boundary is historical data. Tapfiliate's migration guide says that historical conversions, customers, and payments cannot be imported through its standard migration process. A separate Tapfiliate guide now documents bulk conversion imports with required fields and limits, so confirm the exact scope with Tapfiliate before treating any historical records as portable.
This guide is for Stripe SaaS teams moving from Rewardful to Tapfiliate. It focuses on the operational choices that can change affiliate attribution, links, commissions, and payout records. Confirm current vendor terms and your own contract before cutover.
Quick answer: what moves and what does not
| Area | Safe planning assumption | Migration action |
|---|---|---|
| Affiliate records | Tapfiliate supports affiliate imports, while Rewardful offers export help | Export the full affiliate list, then map identity fields before inviting anyone |
| Historical conversions | The standard Tapfiliate migration guide says historical conversions, customers, and payments cannot be imported | Preserve the old reports and get written confirmation before planning a backfill |
| New conversion records | Tapfiliate documents CSV conversion imports with required fields, a 2,500-row limit, and a 25 MB file limit | Use a small pilot only after the destination fields and commission rules are approved |
| Affiliate links | A normal move can create new referral links; custom links can recreate an old structure with developer work | Build an old-link map, test redirects, and keep old URLs active during the transition |
| Stripe events | Rewardful uses Stripe webhooks for customer and invoice events; Tapfiliate needs its own click and conversion setup | Test trials, paid invoices, renewals, refunds, disputes, and coupon attribution |
| Payouts | Old balances must be handled before the old account is closed | Reconcile and pay approved balances, then record the closing report |
The migration is separate from joining a vendor's affiliate program. FindAffiliates has Rewardful, Tapfiliate, FirstPromoter, and PartnerStack pages for publisher research. Their commission and cookie fields do not describe a merchant's post-migration tracking configuration.
Step 1: Freeze the migration scope
Write down what is changing before anyone edits a tracking script. Record the Rewardful program name, commission types, coupon rules, recurring behavior, approval state, payout schedule, refund policy, and active affiliate count.
Create two separate scopes:
- The launch scope contains new clicks, trials, purchases, renewals, refunds, and payouts that Tapfiliate must handle from the cutover date.
- The archive scope contains old clicks, conversions, customer history, commission decisions, payouts, and disputes that must remain available for support and accounting.
This split prevents a common mistake: trying to reproduce every historical detail before the new platform can track the next customer. The first goal is correct future attribution. Historical reconciliation can be separate.
Link the migration to the affiliate software migration checklist for SaaS, then add vendor-specific fields. The broader Tapfiliate vs Rewardful vs PartnerStack comparison helps with selection, but it is not a cutover runbook.
Step 2: Export Rewardful before cancellation
Rewardful says the data belongs to the customer and that its team can help with an export or migration. Start the request while the account is active. Do not wait until the subscription is canceled or a billing event is under review. Read the Rewardful export guidance and save the request and resulting files with the migration record.
The export should cover more than a list of names. Capture, where available:
- Affiliate ID, email, name, referral token, approval status, and payout details.
- Referral links, coupon codes, landing pages, and any custom identifiers used in your database.
- Clicks, referrals, conversions, commissions, commission status, customer IDs, invoice IDs, and timestamps.
- Refunds, reversals, disputes, manual adjustments, and payout history.
- Commission rules for one-time, recurring, trial, coupon, upgrade, downgrade, and refund events.
Keep an untouched source export and a working copy. Version the files if your team has an audit convention. This gives support and finance a stable answer when an affiliate asks why a pre-cutover conversion was paid in one system and a later conversion was recorded in another.
Step 3: Map affiliates, links, and records
Create a mapping table before importing affiliates. The key should be stable across both systems, such as a stable affiliate ID. Do not use only a display name because names and email addresses can change.
| Mapping field | Why it matters | Check before import |
|---|---|---|
| Stable affiliate ID | Connects old payouts and support history to the new record | Preserve it in metadata or the migration ledger |
| Email and status | Prevents duplicate invitations and accidental activation | Normalize casing and confirm approved, pending, and rejected states |
| Old referral token | Keeps a searchable reference to the old link | Store it even if the new token differs |
| New referral code | Creates the destination link and attribution key | Test uniqueness, case behavior, and reserved words |
| Coupon code | Can create a second attribution path | Check ownership, expiration, and duplicate codes |
| Historical balance | Keeps finance aligned with the old platform | Reconcile before enabling new payouts |
Tapfiliate's standard migration flow can create new referral links. If affiliates already use old links, replacing every URL on launch day is risky. Tapfiliate also documents custom links that can recreate an old URL structure and map a short code to destination tracking. Developer work is required to resolve the code and pass the click to Tapfiliate. Review the Tapfiliate custom-link migration guide.
Use one of these link strategies and name it in the cutover decision:
- New links with a communication campaign and a redirect period.
- A controlled redirect or resolver that maps old paths to new tracking.
- Tapfiliate custom links with application code, metadata, click tests, and rollback.
Never delete the old mapping until reports, support tickets, and active campaigns show that the old URLs are no longer generating legitimate traffic.
Step 4: Rebuild Stripe tracking and commission rules
Rewardful's Stripe integration uses webhook events to associate customers, invoice payments, and refunds with referrals. Its documentation explains that commission calculations can follow the amount actually paid and can be recalculated after a refund. Record those rules in plain language before translating them to Tapfiliate.
Tapfiliate's current Stripe guide separates the initial click and conversion setup from the later recurring or lifetime commission connection. The guide says the Stripe connection can handle recurring commissions, refunds, and disputes after the initial JavaScript or API connection is in place. That means installing the Stripe connection alone is not enough to prove a new customer was attributed.
Use the Rewardful Stripe integration notes and Tapfiliate Stripe integration guide as references. Confirm the Stripe customer ID, charge ID, invoice event, coupon, and amount fields for each path. Do not let two systems claim the same live conversion.
Step 5: Run parallel tests before cutover
Create a test affiliate and use a fresh browser for each scenario. Record the expected affiliate, customer, amount, commission, status, and destination report. Test at least:
| Scenario | What to verify |
|---|---|
| Fresh click and signup | The click survives the landing-page flow and the correct affiliate is retained |
| Free trial | The trial is recorded once and converts correctly when the first paid invoice arrives |
| Immediate purchase | The charge amount and customer ID reach the intended conversion record |
| Renewal | Recurring commission follows the approved rule and is not duplicated |
| Upgrade or downgrade | The changed amount uses the expected commission treatment |
| Full or partial refund | The reversal or adjustment appears in the right record |
| Failed payment or dispute | The status and future payout treatment are clear |
| Coupon conversion | Coupon attribution does not override a valid link unexpectedly |
| Duplicate event | Replayed webhooks do not create a second conversion |
| Payout | Approved balance, currency, timing, and status match the operating policy |
Run the same test cases through the old and new reports only while the old environment is a safe test path. Do not create live duplicate conversions merely to compare dashboards. A sample ledger with expected outputs is usually enough.
What to do with historical commissions
Treat historical commissions as an accounting and support archive unless the destination vendor confirms a safe import path in writing. The Tapfiliate migration guide says historical conversions, customers, and payments cannot be imported through the standard migration. Its separate conversion-import guide documents manual or CSV creation with required fields such as external ID, amount, created time, affiliate email, and program, plus limits of 2,500 rows and 25 MB per import.
That import path may help with a narrow reconciliation sample, but it does not prove that every Rewardful field, status, refund, or payout can be reproduced. Ask how imported rows affect commission calculations, customer lifetime state, duplicate detection, and payout reporting. Keep the original export.
If the answer is incomplete, publish a boundary: “Rewardful remains the source of truth for pre-cutover history. Tapfiliate is the source of truth for new events after the agreed timestamp.” Give support and finance the timestamp, link policy, and escalation owner.
Common migration mistakes
Canceling before the export is complete
The export, balance reconciliation, and support request should be closed before cancellation. A screenshot of a dashboard is not a sufficient archive.
Assuming affiliate codes stay the same
New referral codes, old paths, coupon codes, and stable IDs are separate fields. Build the mapping and test the link that a real affiliate already uses.
Double tracking the first conversion
Two active scripts or two API calls can create duplicate attribution. Choose one owner for the conversion event and verify event IDs in logs.
Treating vendor affiliate terms as merchant settings
The Rewardful and Tapfiliate pages on FindAffiliates are useful for researching publisher offers. Their commission rates and cookie fields do not tell a merchant how its own Stripe events or refunds will be tracked.
Ignoring old balances and open disputes
An affiliate may be owed money even if the new platform is ready. Reconcile approved, pending, reversed, and disputed amounts before the final payout decision.
Launching without a rollback
Keep the old reports, link map, event log, and prior tracking configuration available for the agreed rollback window. Define who can pause the new script and how support will identify events on each side of the cutover.
Final cutover comparison
| Decision | Rewardful archive | Tapfiliate launch |
|---|---|---|
| Historical records | Preserve exports, balances, and reports | Import only an approved sample or supported subset |
| Affiliate links | Keep old paths available during rollback | Issue new links or implement a tested custom resolver |
| Stripe ownership | Stop after the agreed final event | Own new click, conversion, renewal, and refund events |
| Support answer | Use the pre-cutover timestamp | Use the post-cutover timestamp |
Key Takeaways for Rewardful vs Tapfiliate Migration Guide for Stripe SaaS
The safe Rewardful vs Tapfiliate migration sequence is export, map, rebuild, test, settle, and cut over. Make historical data a documented boundary instead of an assumption. Preserve old links or redirect them deliberately, prove the first Stripe lifecycle events in a controlled test, and keep the old export available for finance and support.
FAQ
Can Rewardful data move to Tapfiliate?
Affiliate records can be mapped and imported, but do not assume that every historical conversion, customer, payment, commission status, or payout will transfer. The standard Tapfiliate migration guidance excludes historical conversions, customers, and payments, so confirm any separate import plan in writing.
Will old affiliate links keep working?
They can keep working if you preserve the old route with a redirect or build a tested custom-link resolver. New links may use different referral codes. Do not turn off the old path until the mapping and attribution tests pass.
Does Tapfiliate preserve historical conversions?
Not through the standard migration process described in its migration guide. A separate CSV workflow supports manually created conversions with documented fields and limits, but that is not the same as a complete historical migration.
Should Stripe be disconnected first?
No. Export data, settle the old program, implement and test Tapfiliate's initial click and conversion path, verify recurring and refund behavior, then switch ownership at a defined timestamp. Disconnecting first can remove the evidence you need to diagnose a failed cutover.