Thanks for the explanation and visual, Eileen @Eileenmcnaughton. What is contributing to the Gr4vy edge cases and can we advocate with them to reduce these in any way? Also, concerning the credentials piece, I regret you are looking at that as an overhead piece at all. What can we do to improve that? I can get you console access as soon as we have it, but is there more to 'credentials' than I'm thinking?

@Eileenmcnaughton I'm reading through this thread and I feel a certain disconnect that I want to note here. First, in the initial design meetings with Gr4vy and Finance for the recon, we established that we would move toward a transaction level recon and not a batch recon. Gr4vy would send us the fees associated with each transaction which obviated the need for batches. We did not ask them to build a batch recon report. Further, as I understand it, Gr4vy adds richer data in their report than the PSP themselves as they include the Gr4vy transaction ID, the Recon ID and the metadata that can't be sent to the downstream processor. I'm now confused with the comments above as you are approaching this in an entirely different way than was originally intended and doesn't support the notion of the recon as in the modern PSP scenario (transaction detail vs batch). Can I suggest a call with Gr4vy and yourself and Elliot to level-set? I feel somehow there is a disconnect and perhaps in talking to them and you will better understand the original intent and the intent of their solution in this whole undertaking. Finance was at the table and agreed to it at the time. It is unfortunate that Angelito departed mid-project as I feel we lost perspective and as I haven't been in your convos with Finance, I didn't really get how you were looking at this. I'll suggest a time for a call to discuss. I hope you are amenable to that.

@Eileenmcnaughton Thanks Eileen. I think it is worth pressing Gr4vy to get this process up to snuff. I am going to take that feedback to them and press for updates/modifications. Thanks for spelling it out.

@Eileenmcnaughton The only objection I have here is that we are not onboarding new processors in 3-5 years time but NOW. We are contracting Checkout.com as I write this and Stripe is also already added to the Gr4vy platform and we are processing through that already. We want to use the Gr4vy platform for what it was intended to be used for, Orchestration. Therefore, the consolidated file is key for this to avoid having to ask FRTech to build out integrations to each independent output file and waiting for that work on top of other priorities we have which delays the benefit of orchestrating traffic but some unknown timeframe.

Isn't the flow that the ACH transactions actually DO settle but they are prone to returns because there is no guarantee (like an authorization in a credit card). I see no issue with sending a confirmation of the transaction, i.e., thank you and rescind it when /if a return comes in.

Re -opening this as we are looking for the API to support ALL payment avenues via Chariot and not just Paypal as indicated in the referred task above.

noted.

Bravo. Thanks @Ejegg ! @RKumar_WMF do we have someone who can test in CZ?

We use 'donate via bank account' on our Ways to Give Page. I suggest we stay consistent with that. Agree 'ACH payments' is less desirable.

@Ejegg Hi Elliott, it looks like Vipps does not support recurring. We'd have to do this via Mobile Pay. From Adyen:

@Ejegg Elliott, did you implement recurring via mobile pay as well?

cc: @RKumar_WMF fyi

Thanks both. Starting to come into focus.

@IAckerman-WMF I am uncertain. While FRTech is mapping the data in Civi, I assume that Civi data will reside in the Data Lake and we can build reporting around the recon for Operations, correct? There is a reporting need for Operations to validate the Civi data to PSP to Intact, I think to verify accuracy. It is unclear to me how we are going to get such a report at this time. @ERoden-WMF Your thoughts?

@Damilare I have included our new account reps on the case to see if they can assist.

I don't see any value @Eileenmcnaughton that Gr4vy would add other than to offload FRTech's work. I was struggling to see why we could use them other than to avoid FRTech the API integration work. If it is easier, then that settles it .

@Eileenmcnaughton Yes, by all means, let's ask for the credentials. The only reason we thought Gr4vy could be in the flow was that it would be less work for FRTech but if it is easier, then let's take that approach. I will see what we need to do to get those credentials. Stay tuned.

Analytics directed us to FRTech if that is helpful

@RKumar_WMF Rakhi maintains the list. Hi Rakhi, Can you update and place the link here?

I suggest only leave Paypal.

thank you @Ejegg

@XenoRyet Dylan, can you tell us if this is on track given that it is now live?

@Lars @SBurnett-WMF Hi Lars, Stacey indicated that you had a timeline around this need. Are we still talking January or sooner? Many thanks.

@Ejegg Great news! cc: @RKumar_WMF

How many donor complaints do we get on the flow like this? I would be reticent to add steps to the flow unless we felt it was a big issue for many donors.

We are going with the componentized approach. If we decide to do the full integration to the API, we are making inquiries with Gr4vy.

We are pursuing a componentized call approach to see if Peter/Online can enable this in the Ways to Give page and ultimately the banners for 6ENC testing ( per the agreement with MGFE and Online). In the coming months we should look at a proper implementation of this payment type. I am making inquiries with Gr4vy per the API spec at the top of this task and will advise further their response.

{F66750759}Thanks for the quick assessment @Ejegg!

@Ejegg Hi Elliott, this will always be outside of Gr4vy. Chariot is an alternate platform for handling offline donations such as DAFs. We don't intend to include in the Gr4vy flow. I hear you on being more work than we thought. @CaitVirtue @RLewis I am copying you in for awareness on this. The DafPay button via Chariot will be more work than we can get done in time for month end for busy season now that FRTech have made an assessment. Letting you know as I know there was hope we could fit this in for busy season, but it doesn't look feasible unfortunately. cc mdemos.

@AKanji-WMF Hi Anil, will this be possible to add before the end of the month? I have concluded that FRTech WOULD need to enable this button, i.e., make the API call /transmit the donation amount to Chariot so Peter can enable it. No importing audit files, etc.

Major Gifts would like to have this enabled for peak season this year, which means by the end of OCT. @Pcoombe for awareness.

Adding additional detail here on the request at hand. In order to move DAF acceptance from Overflow to Chariot, we will now need to display Chariot's DAFPay button on our donation form along with other payment methods (when the Online team elects to trial this payment mechanism). In our form, a donor will chose the amount to be donated and if they choose DAFPay as the payment instrument, we will need to call the Chariot API and send the nominated amount to the Chariot platform to complete the transaction on the Chariot platform. All financial reporting will be manual and transaction information will be loaded into Civi by the DP team vs pursuing any automated daily output file. @XenoRyet @AKanji-WMF

Christine was able to confirm that recurrings are now resumed via Mexico since Dlocal made the switch of processors. All has returned to normal in Mexico. @MSuijkerbuijk_WMF for awareness.

Dlocal have advised today that they have migrated MX to another processor and asked us to now retry the billing attempts. @jgleeson can we retry current month to assess viability without derailing your plan above?

Thank you @EBrill-WMF . We will cut over to Donate Wiki and watch 3DS further there. Much appreciated.

Posting this note here concerning some of the audit discrepancies we have been seeing of late between Gr4vy and Dlocal. In speaking with Jules who heads up all things data at Gr4vy, he points out that in a current sprint they are working on ingesting the audit files into their data platform to capture these late-stage updates. He acknowledges the challenge of not properly synching refunds to the transaction and other manual handling updates. Chargebacks will be another thing they add. He stated that this is more problematic with Dlocal as some of you are probably aware as they don't give clear responses in some cases where that doesn't happen with Adyen.

Added to Gr4vy log 7.29 for discussion

Raised with Gr4vy @RKumar_WMF 7.29.25

Update here from Jack that didn't make it into this phab: https://wikimedia.slack.com/archives/C045WH0QYS2/p1752862583805239. We closed this out on the log @AKanji-WMF , should we do so here too?

Thanks so much!

@Ejegg Can you confirm that this is released? Do you need me to test?

@Ejegg Hi Elliott, I ran a transaction with the Gr4vy link and see that the Adyen logic is being called on my transaction (prefer not triggered). Adyen transaction ID:
NWXDGG3685LMLC69.

That would be great. Do we have to ask FRTech for it each time? It would be great to have it on demand for such cases of a donor in waiting who wants to give now. Interesting that we can do this.

@dkozlowski. Any update on this task since Jack singed off last week? It's the last thing we are waiting on for cut over.

@Ejegg Sure! Can we share a link to this URL parameter with donors? The 12k block we have on our systems thwarts the larger donations like this. Are you saying that that wouldn't exist with this parameter?

@MDemosWMF Can we get this transaction in civi from the above info? Rosie @RLewis will know which CID/contact to apply it to. In the future we should create these links and require the USER info. That is doable in the PaybyLink feature.

@mbeattie. Adyen doesn't use the 30 days x3 by design. They are relying on machine learning and best practice for the market to recover the transaction. This may mean varying times and varying attempt numbers. So far, it has had a positive effect on conversion to use their logic.

@jgleeson Is this deployment indicating this matter is now /soon to be resolved once deployed?

@jgleeson @RKumar_WMF I was able to find some AMEX testers and was able to test the AVS results as above. I've captured the results here.. The only difference I see is that in response 26, Gr4vy /Adyen approved a complete no match where in our direct connection, it declined this response.

Do we know why it was missed as we'd like to use this manual facility for large gifts again in the future?

I spent some time today testing out AVS responses through Gr4vy. I have Visa debit and credit cards at my disposal. I tested out the logic in the phab and received the intended results from the mapping on the AVS logic (see AVS test on the Gr4vy tracker). Is this enough to satisfy that the Gr4vy mapping is corrected or do we need to test this out on AMEX as well?
https://docs.google.com/spreadsheets/d/117qd1q2wEGjjP1FtkOkO4RHGu6cYN_Eh9l0kVtAC2qo/edit?gid=31242775#gid=31242775

We have enabled Amazon Pay via Stripe via Gr4vy. We are asking for it to be fast tracked under phab: T398377: Fast track Phab for Amazon Pay

@MBeat33 @MDemosWMF @RLewis Thanks Michael, we will look for it next week.

@AKanji-WMF @dkozlowski. I think this is a question for you.

@mbeattie. I entered this task https://phabricator.wikimedia.org/T399033 as #1 was a donation made by a donor using PaybyLink at Adyen on our core account but I do not see it in Civi.

This may be on hold for now. Engage is not PCI compliant presently for MOTO to Gr4vy.

Yes! It's exactly what it would do! @AKanji-WMF

@AKanji-WMF . Here is the 'fast track' enablement info for VIPPs:
What markets is it available in:
Norway

Adyen has approved VIPPS usage for Wikimedia as of 23 Jun.

Closing this ticket as it is duplicate to: https://phabricator.wikimedia.org/T389975

@jgleeson I'm seeing many transactions staying in a 'sent for settle' status at Adyen since we cut over. I am also seeing this error when I look in the Gr4vy console for JCB - I can't search on JCB but I don't see many, I manually found this one and it says it is an 'unaccepted payment type'.

@ajohnson Amber, Gr4vy is working to pass the inovice ID on the capture. It is an open ticket which they hope to have resovled in the next couple of weeks. I should have said that above. Please stand by and you will eventually see it I expect in the console.

@krobinson @MBeat33 @SHust @ajohnson I am looping DR in about this Paypal workflow as this will mean that DR will need to look up a Paypal transaction using an Invoice ID vs the transaction ID in the Gr4vy console. Unfortunately, this is how Paypal has implemented the IDs (one for the donor and one for the merchant that are separate and distinct) and the invoice ID will be the only way to tie the donor inquiry to the transaction on our end in the Gr4vy console. @RKumar_WMF

More from Paypal on whether the invoice ID exists. They walk me through the flow and what has to be captured here:

When posing the dilemma to Paypal about not wanting to use the Paypal console to research donor issues, but instead Gr4vy's, they came back with this as an alternative:

Adyen reached out to JCB with no response. Looking to see if their partnership manager can help us get JCB assistance.

More from Paypal regarding the above today: If a user reaches out to you with the transaction ID from their transaction, you can search this in your account. Searching the buyer's ID will provide a result of the transaction in your account.

@Ejegg After some fact finding this week, we learned from Paypal that the IDs do not match by intention. From Paypal: ' Transaction ID confusion
When you process a transaction, you will get the Sellers transaction ID provided back to you by PayPal. This is used for your records and for tracking the payment. The buyer sees a different transaction ID in their account for the same payment. You will not see the buyer's transaction ID and the buyer does not see the Seller's transaction ID
For example:
v2/payments/authorizations/42K57312KT114553F/capture
Method POST | Status 201 | 2025-05-28 11:45:59 PDT

@AMJohnson @Damilare Response from Adyen pertaining to this issue. I sent them the following 3 examples from the above: W6RTNKCMFKGK5CB9, Example 2: MV9SVV8K44637635
Example 3: VGXKMV3JNKQ3H7B9. From Adyen:
//"When I checked the logs, I do not see any cancel request reaching us for the transactions that you shared.
Looking also at the screenshot, the url used also seems strange to me.
Our cancel endpoint looks more like [pspReference]/cancels, as you can see in our API explorer: https://docs.adyen.com/api-explorer/Checkout/71/post/cancels

@AMJohnson Hi Amber, regarding the missing email in #2 at the start of this task, here is what we learned from Paypal this week: "When you process a transaction, you will get the Sellers transaction ID provided back to you by PayPal. This is used for your records and for tracking the payment. The buyer sees a different transaction ID in their account for the same payment. You will not see the buyer's transaction ID and the buyer does not see the Seller's transaction ID"

@AMJohnson @krobinson Hi Amber, regarding the missing email in #2 at the start of this task, here is what we learned from Paypal this week. It seems that the move from billing agreement via our direct connection to a vaulted Paypal flow via Gr4vy has a different workflow. From Paypal: //"This is a difference in the Billing Agreement flow vs the Vaulted Payment Token flow. The process for the Vaulted payments use direct webhooks to update the API caller account directly when changes are made. You can configure the webhook listener to generate an email to be sent out if that is what is needed for the integration. There won't be a way to trigger a PayPal branded email notification from this though.

I provided more detail to Adyen today per their request 5 June.

@jgleeson This is pertinent to Fundraise Up transactions only, correct?

Looks great. Thanks.

@AnnWF I have been able to test alas and see this is working.

@jgleeson Hello Jack, thanks for the rapid action here! Can you possibly add this language to the SEPA page [[ https://payments.wikimedia.org/index.php?title=Special:AdyenCheckoutGateway&appeal=JimmyQuote&country=FR&currency=EUR&payment_method=rtbt&payment_submethod=sepadirectdebit&recurring=1&frequency_unit=month&uselang=en-gb&amount=2.5&opt_in=0&wmf_medium=spontaneous&wmf_campaign=spontaneous&wmf_source=fr-redir.default%7Edefault%7Edefault%7Edefault%7Econtrol.rrtbt.sepadirectdebit&wmf_key=otherAmt_0%7EvalidateError_1%7Etime_10 | name ]]to avoid further confusion on this?

@RKumar_WMF we should test for these items in our previous implementation of iDeal when we get to that point which are included in this task: https://phabricator.wikimedia.org/T372571

@AnnWF Hi Wenjun, I just retried and the fields are gone but I cannot proceed with the transaction. Same error:

@AnnWF Wenjun, thanks for removing the email. Looks good. Unfortunately, when I seek to log in to my bank account I get this error:

I tested the ACH flow since this merge and ACH /Trustly is no longer working on Donate wiki @AnnWF . Also, I see it is still requiring the email field. Can this also be removed{F60250084}

Jack confirms the numbers used were the same and Adyen's response doesn't explain the issue. Back to the drawing board.