Events
In the Rebilly rules engine, an event is a preconfigured occurrence. An action is an operation that executes when an event occurs. This topic describes all event types and actions available for each event.
Core events
Customer created
Executes when a new customer is created. A common use case for this event is to notify a third party of the new customer record. To configure this event, see Create a rule or bind.
Actions available for this event:
Dispute created
Executes when a dispute, also known as a chargeback, is added to one of your transactions. A common use case for this event is to stop active subscriptions for the customer who started the dispute, or blocklist this customer based on a certain attribute.
To configure this event, see Create a rule or bind.
Actions available for this event:
- Blocklist customer ID
- Blocklist email
- Blocklist fingerprint (device)
- Blocklist IP address
- Blocklist payment card
- Stop subscriptions
Gateway account requested
Executes when a customer attempts to make a transaction for the first time. A common use case for this event is to assign a gateway account to process the transaction based on certain conditions, such as: payment card attributes, bank country, currency, and so on. To configure this event, see Create a rule or bind.
Actions available for this event:
NSF response received
Executes when a Non-Sufficient Funds (NSF) response is received. A common use case for this event is to notify your customer, or to add an NSF fee. To configure this event, see Create a rule or bind.
Actions available for this event:
Payment card created
Executes when a payment card is created. A common use case for this event is to schedule a reminder at a point in time before or after the card's expiration date. To configure this event, see Create a rule or bind.
Actions available for this event:
Ready to pay requested
Executes when a customer requests available payment methods for a payment.
A common use case for this event is to display the most relevant payment method options for a customer, based on their geographic location. For example, you may need to display different payment methods for customers in Canada and Germany, because they have different payment method expectations. You may also prioritize the customer's active payment methods. To configure this event, see Create a rule or bind.
Ready to payout requested
Executes when a customer requests available payment methods for a payout. A common automation for this event is to display the most relevant payment method options for the customer, based on their geographic location.
To configure how a gateway manages payout requests, set the ready to payout instruction in gateway account settings. For more information, see Set up a gateway.
Risk score changed
Executes when a transaction risk score changes. Each transaction has a numeric risk score attribute. A common use case for this event is to assess the risk score value. If the score is greater than a permitted amount, a risk agent is notified, or a blocklist action is performed on the customer who initialized the suspicious transaction.
A risk score may change based on actions that related to other events. For example, the Transaction process requested and the Transaction processed events can both execute this event and change the risk score.
To configure this event, see Create a rule or bind.
Actions available for this event:
- Blocklist customer ID
- Blocklist email
- Blocklist fingerprint (device)
- Blocklist IP address
- Blocklist payment card
Transaction process requested
Executes at a point just before the transaction process is initialized. This provides an opportunity to review the transaction and perform an action based on its attributes. A common use case for this event is to increase the risk score for suspicious transactions. For example, if a transaction has a billing address in a country which is considered to be high-risk location for online fraud.
To configure this event, see Create a rule or bind.
Actions available for this event:
Transaction processed
Executes after a transaction is processed by a payment gateway. Use this event to configure actions based on the result of a transaction.
A common use case for this event is to blocklist a customer, if a transaction is declined with a reason that suggests fraud. If the decline reason is not linked to fraud, this event can be used to retry payments.
To configure this event, see Create a rule or bind.
Actions available for this event:
- Blocklist customer ID
- Blocklist email
- Blocklist fingerprint (device)
- Blocklist IP address
- Blocklist payment card
- Stop subscriptions
Billing events
Invoice issued
Executes when an invoice is issued. A common use case for this event is to send an email that includes the invoice, or to schedule a reminder. Reminders may be used to alert customers that a payment is automatically collected on a certain date. To configure this event, see Create a rule or bind.
Actions available for this event:
Invoice past due
Executes when an invoice is past due. A common use case for this event is to send an email to the customer to remind them to pay the invoice. To configure this event, see Create a rule or bind.
Actions available for this event:
Invoice past due reminder
Executes when an invoice has been past due for an amount of time. A common use case for this event is to send the customer an email reminding them to pay the invoice. To configure this event, see Create a rule or bind.
Actions available for this event:
Payment card expiration reminder
Executes when a customer's payment card is due to expire. A common use case for this event is to send the customer an email, reminding them to update their payment card details. To configure this event, see Create a rule or bind.
Actions available for this event:
Payment card expired
Executes when a customer's payment card expires. A common use case for this event is to send an email to the customer to notify them, and to instruct them to update their billing information.
Alternatively, Rebilly can be set to guess a new expiration date. For each guess, the system attempts a $1 authorization. On successful authorization, the customer's payment card will be updated to use that card.
To configure this event, see Create a rule or bind.
Actions available for this event:
Renewal invoice issued
Executes when a renewal invoice is issued. A common use case for this event is to email the invoice to the customer. To configure this event, see Create a rule or bind.
Actions available for this event:
Renewal invoice payment canceled
Executes when a renewal invoice payment is canceled. A common use case for this event is to send an email to the customer, or churn the subscription, if there is a blocklist match. To configure this event, see Create a rule or bind.
Actions available for this event:
Renewal invoice payment declined
Executes when a renewal invoice payment is declined. A renewal invoice is a recurring invoice for a plan or product which is charged automatically. A common use case for this event is to email the customer and inform them why their payment was declined. This event can also be used to schedule a payment retry.
To configure this event, see Create a rule or bind.
Actions available for this event:
Subscription activated
Executes when a customer's subscription is activated. A common use case for this event is to send a confirmation email to the customer. To configure this event, see Create a rule or bind.
Actions available for this event:
Subscription canceled
Executes when a customer's subscription is canceled. A common use case for this event is to notify third-party services, and request to disallow access for the customer. Another common use case is to use this event to cancel all scheduled payments for the customer.
To configure this event, see Create a rule or bind.
Actions available for this event:
Subscription created
Executes when a customer signs up to a subscription service. At this point in the order lifecyle, the subscription is in the pending state and is not active. The order becomes active when an invoice is paid, or when a payment instrument is verified for free trial.
A common use case for this event is to schedule a payment reminder, send a confirmation email to the customer. To configure this event, see Create a rule or bind.
Actions available for this event:
To manage the abandonment of pending orders, see Abandon a pending order. To set this configuration using the Rebilly API, see Configure automatic abandonment of pending orders.
Subscription renewal reminder
Executes when a subscription renewal is approaching. A common use case for this event is to send an email to the customer to inform them. To configure this event, see Create a rule or bind.
Actions available for this event:
Subscription renewed
Executes when a customer's subscription is renewed. A common use case for this event is to schedule a payment for the subscription when a subscription is renewed. To configure this event, see Create a rule or bind.
Actions available for this event:
Subscription trial converted
Executes when the first invoice after the trial period is paid. A common use case for this event is to send an email to the customer, or schedule a reminder. To configure this event, see Create a rule or bind.
Actions available for this event:
Subscription trial end reminder
Executes when a subscription trial end date is approaching. A common use case for this event is to send an email to the customer before the renewal date. To configure this event, see Create a rule or bind.
Actions available for this event: