In T324298#8648485, @Damilare wrote:

Having set up the Recurring process on Smashpig and looked through the recurring charge process on Civi, I'm certain that the CRM_Core_Payment_SmashPig civi class would be able to charge the Dlocal recurring card payment using the createPayment method in the Dlocal CardPaymentProvider class. So far I don't see any need for any Dlocal specific tweaks on the CRM_Core_Payment_SmashPig civi class.

The Dlocal CardPaymentProvider's createPayment method checks for the presence of the "recurring_payment_token" (this is the "card_id" from Dlocal) in the request params, which it uses to determine if the payment transaction is a recurring charge payment. If it is a recurring charge payment, the payment is captured in a single API call, else the payment is divided to the Auth/Capture steps for fraud checks.

This task would be closable after running an end to end test upon completion of T324297. The end to end test would cover:

• The recurring donation on Donation Interface Frontend.
• Consuming the queues and ensuring the recurring Donation has a row in the civicrm.civicrm_contribution_recur table afterwards. Get the id of the recurring donation on this table.
• Trigger a charge for the Dlocal recurring using this

drush @wmff -vv cvapi job.process_smashpig_recurring contribution_recur_id={id}

Hi @SuvamManna, I'd have to complete this task as it's an impediment for some other tasks and the team has a deadline for the feature this task supports.

Hi @jgleeson, yes the document field is required to process the recurring charge job. Thanks for the link to the mapper, I think we'd also have to add the additional param in the getPaymentParams as well, I've created this task T331288 to get that done.

Hi @SuvamManna, are you able to work on this task or do you need support?

Having set up the Recurring process on Smashpig and looked through the recurring charge process on Civi, I'm certain that the CRM_Core_Payment_SmashPig civi class would be able to charge the Dlocal recurring card payment using the createPayment method in the Dlocal CardPaymentProvider class.

For PyCharm users with DjangoBannerStats: https://etherpad.wikimedia.org/p/pycharm-debuging

The link in the description seems to be the error codes for Payout transactions. Here's the link for Payin response status codes: https://docs.dlocal.com/reference/payment-status-codes

In T324745#8454001, @Hannah_Njoroge wrote:

Also we should have a way of collecting info on why the user has skipped the task so that it can help in future improvements of the app

Thanks @Marostegui, looks like I do have the access. I was just able to sign in with my WikiTech LDAP.

Yes that's correct. Pardon my ignorance, but does this also mean I already have Turnilo access?

Apologies @Marostegui I've added updated the description with the required template.

Tested this and I only saw the "information not secure" error when the Callback URL is set on an HTTP address. The error didn't come up when I changed to https with my proxy forwarding URL in the Callback URL field on dLocal's sandbox dashboard.