[Feature Request]: Order of events

[8ctopus]

Suggestion / Feature Request

I have a suggestion to simplify the customer side implementation of subscriptions: now, the events triggered when a user subscribes: BILLING.SUBSCRIPTION.CREATED, BILLING.SUBSCRIPTION.ACTIVATED and PAYMENT.SALE.COMPLETED can be sent in any order which makes processing much harder. Here's an example from my sandbox:

[2023-11-24 08:19:14] DEBUG new event - PAYMENT.SALE.COMPLETED - 1F571360LH117700T
[2023-11-24 08:19:14] WARNING payment sale completed called before activated - I-23A00KCEW0SF
[2023-11-24 08:19:19] DEBUG new event - BILLING.SUBSCRIPTION.CREATED - I-23A00KCEW0SF - status - APPROVAL_PENDING
[2023-11-24 08:19:19] INFO Process 1 pending events...
[2023-11-24 08:19:19] INFO Process pending events - OK
[2023-11-24 08:19:24] DEBUG new event - BILLING.SUBSCRIPTION.ACTIVATED - I-23A00KCEW0SF - status - ACTIVE

It does not make much sense to get a completed payment for a subscription that doesn't yet exist.

It would make implementation a lot easier if the order would be fixed:

1. BILLING.SUBSCRIPTION.CREATED
2. BILLING.SUBSCRIPTION.ACTIVATED
3. PAYMENT.SALE.COMPLETED

[NavinPayPal]

@8ctopus : Sent this to the team to look into it, will let you know when I hear back.

[8ctopus]

Thank you. Had a more awkward case recently: the transaction refund event PAYMENT.SALE.REFUNDED was sent before PAYMENT.SALE.COMPLETED.

[NavinPayPal]

As per the teams response "This feature is not likely to happen. However, the event that holds utmost significance is PAYMENT.SALE.COMPLETED; the other events don't seem to have good use cases.

[8ctopus]

@NavinPayPal The team's response doesn't make sense as you cannot create a customer receipt or invoice on PAYMENT.SALE.COMPLETED event without the BILLING.SUBSCRIPTION.ACTIVATED event. Why? payment sale completed does not store any user info. The team member that has responded is definitively mistaken.

In addition, it would be great for issues reported to be given more attention and faster response times.