Stripe is built in, so you do not need any of this to charge for a level. These hooks are for wiring memberships to anything else: another payment system, an autoresponder, a webhook, your own automation.
Granting a level from your own code:
Call RAXM_Members::add with a user id, a level id and an array carrying a source and a transaction reference. It is idempotent, so calling it twice for the same sale is safe.
Reacting to membership changes:
- raxm_member_added fires with the user id, level id and the row, whenever anybody gains a level
- raxm_member_registered fires with the user id, level id, email and name, which is the one to hook for an autoresponder
- raxm_member_removed fires with the user id and level id
- raxm_member_expired fires with the user id and level id, which is your renewal email trigger
- raxm_member_reactivated fires when a cancelled membership is restored
- raxm_access_denied fires when somebody is turned away from protected content
Programmatic access control:
The raxm_has_access filter receives whether access is allowed, the post id and the user id, and returns whether access is allowed. Use it for rules this plugin does not model, such as access based on something in the member's profile.
Every hook fires on imports too, with a source of wishlist_import or csv_import, so downstream automations stay in sync during a migration rather than firing thousands of welcome emails or missing everybody entirely.
When a payment is recorded:
Every real payment also fires the family payment hook, raix_payment_recorded, with the payment array and a source of membership. It carries the email, first name, type of sale, renewal or refund, amount and tax in cents, currency, gateway, a transaction id, the level slug as the product reference, the level name, and when it happened.
That hook is how the other ResultsAiX plugins can report on your money without any of them owning a shared orders table.
Three rules it follows:
- Test mode never fires it, because a practice purchase must never reach a revenue report as real money
- A refund arrives as its own event with a negative amount, never as an edit to the original
- The transaction id is unique per charge, so a replayed webhook cannot double count
What a paid level does not change:
Nothing above behaves differently on a paid level. raxm_member_added still fires when the payment grants the level, with the order reference in the row, so an autoresponder wired up before you ever charged for anything keeps working untouched.