Hi Simon

Payment Reference could be considered as the Payment Gateway reference. For Worldpay and the likes, there is just one reference value returned so Payment Reference would be the correct term.

Now, for Stripe subs, we generate a renewal order awaiting payment 10 days beforehand - there is no pi_, in_ or ch_ at this point in time so we need to use the sub_ id to chain the orders neatly together. 

For one-off payments in Stripe, this is simpler - we just send in the amount and Stripe takes payment similar to other payment gateways. Stripe creates a pi_ at this point. There is no in_ but there is a ch_ value.

If you create a payment in Stripe directly, it is associated to a customer, payment intent and invoice with ch_, pi_ and in_ values. If it's a subscription, there is also the sub_. and for Stripe manual payments, there is no in_.

So it seems the pi_ is the constant across all the Stripe options. What we could do is add a new column called PaymentID to store this  value once we receive the webhook that the payment is successful. This will then allow you to track down the invoice more easily.

Hi Q

This sounds like a step forward and, from what you've described, should also cover one off items i.e. not subscriptions but for example a ticket purchase (which currently has no info to enable a recon vs Stripe)

I would just point out that "Now, for Stripe subs, we generate a renewal order awaiting payment 10 days beforehand" is not quite accurate. The first renewal is created 10 days before, but subsequent ones are created 30 days beforehand. However,  I don't think this affects the matter.

Thanks

Simon

Hi Simon   Payment Reference could be considered as the Payment Gateway reference. For Worldpay and the likes, there is just one reference value returned so Payment Reference would be the correct term.   Now, for Stripe subs, we generate a renewal order awaiting payment 10 days beforehand - there is no pi_, in_ or ch_ at this point in time so we need to use the sub_ id to chain the orders neatly together.    For one-off payments in Stripe, this is simpler - we just send in the amount and Stripe takes payment similar to other payment gateways. Stripe creates a pi_ at this point. There is no in_ but there is a ch_ value.   If you create a payment in Stripe directly, it is associated to a customer, payment intent and invoice with ch_, pi_ and in_ values. If it's a subscription, there is also the sub_. and for Stripe manual payments, there is no in_.   So it seems the pi_ is the constant across all the Stripe options. What we could do is add a new column called PaymentID to store this  value once we receive the webhook that the payment is successful. This will then allow you to track down the invoice more easily.  

	Gateway Reference	PaymentID
Stripe subscriptions	sub_	pi_
Stripe one-off	pi_	pi_
GoCardless	SBxxxxx	PMxxxxx

   

Hi Simon

Subsequent renewals should not be created 30 days in advance. Please post to your forum for support if this is the case.

Morning Quang

I am basing this on two things - the first is feedback from Julius via Sue, thus (my bold and underline):

Julius has provided his feedback on this:    

If you have a monthly renewal, we generate the renewal order 10 days before for the 1st renewal. We use the order creation date or the subscription end date. Depends which one is earlier.   For order: 343782 if you check the previous order it was created on 07 Oct 2024 00:09 and the sub end on 05 Dec 2024 so the renewal generation would be:   creation date => 07 Oct 2024 + 30 days  = 06 November 2024 => renewal generation date   For order: 343707 creation date => 10 Oct 2024 00:13 + 30 days  = 09 November 2024 => renewal generation date    So as a result there is no -10 days as this is not the first renewal.   If you have any further queries on this, please let us know and I can arrange a call with Quang.   Many thanks,   Sue  

[edit] Secondly, having checked this across a few different clients' instances, this looks to be correct and accurate.

Are you saying it only applies to monthly subs?

I think it's quite important that we have an accurate collective view of this.

Many thanks

Simon

Hi Simon

For monthly renewals, we add 30 days to calculate when to create the renewal order. For the first renewal order only, we minus 10 days in addition so it is there ready and listening for the webhook to confirm when the renewal is paid. Subsequent orders will use this same day per month to generate the next renewal, i.e. we do not minus 10 days again. We updated this logic in the recent release as this was previously moving the order generation date further and further back.

Example:

Hi Quang

Thanks for clarifying - I think I've misunderstood JM's comment and the orders I checked were probably before the update to 9.0.7.4 (which is from October 1st I think?)

We've certainly seen renewals cued up at odd times for the last few years, so this is IMO a good step.

If this is the new logic and it's going to persist may I suggest that the final column in the order report screen (Created) is not the  most useful - maybe "Due/Paid" would be more informative?

All the best

Simon

Hi Simon

Created means when the order was generated and a database record added. This is consistent across Affino for articles, editions, contacts, accounts, etc. This is always useful (for us in particular) to diagnose issues and determine who created it - whether it was a automated system process or human.

We could add a payment date column which we know already from the order and already features in the order export.

For due date, we could possibly pull the Next invoice/Upcoming invoice date from the Stripe API, which would be the most accurate.