I also ran this report out of Dlocal and find that most of the IR transactions are rejecting over the month:

From Dlocal: Hi Evelyn.

I checked some of the transactions.

Transactions with error code 321 are related to subscriptions created with the monthly mode. The sample that I checked is because the prenotify was sent before the next due date. I saw that the ondemand model was first used the 23rd.

Transactions with error code 300 have different reasons.

• Subscription creation: User never completed the subscription, what we also call abandonment:

user may have been redirected but did not complete the transaction
user may have been redirected but close the paytm payment process
user may have been redirected but did not have funds or a way to complete the subscription
user may have not even been redirected to paytm
an error that did not allow the user to complete the payment

• Prenotifications: The prenotification request was successful but

the user may have cancelled or paused the subscription
the user did not have enough funds to pay
I may be missing an additional escenario
We can have a look in tomorrow's call.

Regards.

Sebastian Quintero | Technical Account Manager

e: squintero@dlocal.com

For 321 errors are attributed to WMF rebilling prior to the 30 day billing cycle. We cannot change a monthly to ondemand so we either need to bill on the 30 day schedule or restart the donor on ondemand.

Christine suggests: Remove 24 hour delay to rebill the monthly flow subscribers - next month they will bill as usual. Sebastian notes we could also move to 31 days vs 30 days. Paytm says no issue to bill 31 days. Christine does not know how easy it would be to bill +31, but can remove the delay to bill on the date as the next action to resolve the issue with these rejected recurring donors.

The 300 rejects are legitimate and we cannot do anything to rectify these.

I manually updated 2 scheduled to recur on the 15th to the 16th. I'm going to watch what happens to those two and will update here.

The 2 ones I manually updated to one day later successfully sent the prenotification and are now in pending status. I will check what happens with the actual charge in a day but looks like moving the date will get us past the 321 error in acquirer situation.

Looks like both of the ones in pending failed with "The payment was rejected" and status code 300.

CID 59607042
F-648-47b1f329-8b26-42b9-8453-92cb9fcce099

CID 50346793
F-648-daf6c9e7-df63-41cd-8d23-16739c01d36e

Just to note, those 19 unique recurring transactions that successfully processed in May off their original April setup appear to now be failing in June. I am not sure if this was expected or not.

Error code: 'The payment was rejected" and status code 300. Interestingly, we actually have the failure registering in Civi now for the first time as 'Status: Failing', although not cancelled.
cid=55010963
cid=59548510

The remaining 17 of this batch are due to process [or fail] on Monday 26th June.

Just an update of where this is, from dlocal:
"since the 2oth of June, we are having general rejection (100%) with an unknown error from PayTM which I already raised with them to fix it as soon as possible."

Donor CID 59537908 reached out as the recurring they set up on 22nd April failed in May, and June, and they got our automated 'invite to restart' email. They have basically asked if setting it back up will work, as they do want to give 90 INR a month, and DR is unsure what to advise them, as we've been having a hard time following on as to whether this is fixed.

Basically the question is: are we 100% sure that a new recurring set up today will successfully process (on our side, we know there can always be issues on the donor end), or should we wait on responding?

Thanks!

@EMartin a bunch processed successfully on 6/26 but since then a lot have been failing with status 300 and The payment was rejected.

There have been successful charges every day but the majority are failing with 300.

To @krobinson 's question, @EMartin what do you think here?

@Cstone I see the following reject rate. I think we go back to Dlocal with this as this doesn't seem right: