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

AML list possibly matched

Executes when a customer's data matches an entry in the AML list. To configure this event, see Create a rule or bind.

Actions available for this event:

Account password reset requested

Executes when a customer requests a password reset. A common automation for this event is to send an email to the customer containing verification or sign-up information. To configure this event, see Create a rule or bind.

Actions available for this event:

Account verification requested

Executes when a customer signs-up or requests verification to be resent. A common automation for this event is to send an email to the customer containing verification or sign-up information. To configure this event, see Create a rule or bind.

Actions available for this event:

Application instance enabled

Executes when a new application instance is enabled. A common automation for this event is to send an email. To configure this event, see Create a rule or bind.

Actions available for this event:

Application instance disabled

Execute when an application is disabled. A common automation for this event is to send an email. To configure this event, see Create a rule or bind.

Actions available for this event:

Balance transaction settled

Executes when a balance transaction is settled. A common automation for this event is to send an email. To configure this event, see Create a rule or bind.

Actions available for this event:

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:

Customer one time password requested

Executes when a customer attempts to log in with One-Time Password (OTP) active. A common use case for this event is to email the customer their one time password. To configure this event, see Create a rule or bind.

Actions available for this event:

Customer updated

Executes when an existing customer record is updated. A common use case for this event is to notify a third-party of the change to a 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:

Dispute modified

Executes when a dispute, also known as a chargeback, is modified. A common use case for this event is to send an email to your fraud agent with the status of the dispute.

To configure this event, see Create a rule or bind.

Actions available for this event:

Experian check performed

Executes when an Experian identity check is performed. A common use case for this event is to notify a third party of the result of the check, using a webhook or email notification.

To configure this event, see Create a rule or bind.

Actions available for this event:

Gateway account downtime started

Executes when a period of gateway downtime begins. A common use case for this event is to send an email to notify customers that this gateway is temporarily not available for use.

To configure this event, see Create a rule or bind.

Actions available for this event:

Gateway account downtime ended

Executes when a period of gateway downtime has ended. A common use case for this event is to send an email to notify customers that this gateway is available for use.

To configure this event, see Create a rule or bind.

Actions available for this event:

Gateway account limit reached

Executes when a gateway account transaction limit is reached. A transaction limit may refer to the number of transactions per day, or the amount of a particular transaction. A common use case for this event is to send an email to notify the customer that their transaction exceeds the permitted amount. To configure this event, see Create a rule or bind.

Actions available for this event:

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:

KYC document accepted

Executes when a KYC document is accepted. A common use case for this event is to notify a third-party that the KYC document has been accepted, and to take some further action. To configure this event, see Create a rule or bind.

Actions available for this event:

KYC document modified

Executes when a KYC document is modified. A common use case for this event is to notify a third party that the KYC document has been modified, and to take some further action. To configure this event, see Create a rule or bind.

Actions available for this event:

KYC document rejected

Executes when a KYC document is rejected. A common use case for this event is to notify a third-party that the KYC document has been rejected, and to take some further action. To configure this event, see Create a rule or bind.

Actions available for this event:

KYC request fulfilled

Executes when a KYC request is fulfilled. A common automation for this event is to notify the customer by email. 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 indicates that they are ready to make 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.

Actions available for this event:

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:

Transaction amount discrepancy found

Executes when a transaction amount discrepancy is found on reconciliation. A common use case for this event is to send an email to notify the customer of the discrepancy. To configure this event, see Create a rule or bind.

Actions available for this event:

Transaction declined

Executes when a transaction is declined. A common use case for this event is to send an email to the customer. To configure this event, see Create a rule or bind.

Actions available for this event:

Transaction discrepancy found

Executes when a paid amount differs from the expected amount. A common use case for this event is to send an email to the customer. To configure this event, see Create a rule or bind.

Actions available for this event:

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:

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 modified

Executes when an invoice is modified. A common use case for this event is to send an email to notify the customer that the invoice has been modified. To configure this event, see Create a rule or bind.

Actions available for this event:

Invoice paid

Executes when an invoice is paid. A common use case for this event is to send an email with the invoice to the customer. To configure this event, see Create a rule or bind.

Actions available for this event:

Invoice partially paid

Executes when an invoice is partially paid. A common use case for this event is to send an email with the customer and inform them that the invoice is partially paid. To configure this event, see Create a rule or bind.

Actions available for this event:

Invoice partially refunded

Executes when an invoice is partially refunded. A common use case for this event is to send an email to the customer and inform them that the invoice is partially refunded. 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:

Invoice refunded

Executes when an invoice payment is refunded. A common use case for this event is to send an email to the customer to notify them. To configure this event, see Create a rule or bind.

Actions available for this event:

Invoice revenue recognized

Executes when invoice revenue is recognized. A common use case for this event is to send an email to the customer to notify them. To configure this event, see Create a rule or bind.

Actions available for this event:

Invoice tax calculation failed

Executes when an invoice tax calculation fails. A common use case for this event is to send an email to the customer to notify them. To configure this event, see Create a rule or bind.

Actions available for this event:

Invoice voided

Executes when an invoice is voided. A common use case for this event is to send an email to the customer to notify them. To configure this event, see Create a rule or bind.

Actions available for this event:

Order abandoned

Executes when an order is abandoned. A common automation for this event is to notify the customer by email. To configure this event, see Create a rule or bind.

Actions available for this event:

Order abandon reminder

Executes an order is about to be abandoned. A common automation for this event is to notify the customer by email. To configure this event, see Create a rule or bind.

Actions available for this event:

Order completed

Executes when an order is completed. A common use case for this event is to send an email to the customer to notify them. 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 order 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 reactivated

Executes when a subscription is reactivated. A common use case for this event is to send an email to the customer, or to alert a third party. To configure this event, see Create a rule or bind.

Actions available for this event:

Subscription churned

Executes when a customer's subscription is churned. 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 downgraded

Executes when a subscription is downgraded. A common automation for this event is to notify the customer by email. To configure this event, see Create a rule or bind.

Actions available for this event:

Subscription paused

Executes when a subscription is paused. A common automation for this event is to notify the customer by email. To configure this event, see Create a rule or bind.

Actions available for this event:

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:

Subscription upgraded

Executes when a subscription is upgraded. 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: