Closed alanmoo closed 4 years ago
Sounds good. As soon as y'all determine the key for this value I'll get a PR going.
The key that we use to pass in to Basket? I'd assume card_type
should be fine? @pomax @stephaniemcv any concerns with that? It still gets passed to the same spot in Salesforce regardless of the name.
Yes. I just need to know what it'll be.
Based on the API that Braintree gives us, card_type
looks right to me. I've got a tentative PR up that uses that as new key for the SQS payload.
Is this for all of the donation event types, or just the initial donation
type?
As far as I know, only for donations, so that we can add that information to donation receipt emails.
I believe this needs to work for recurring donations too.
I believe this needs to work for recurring donations too.
I think recurring donations are represented by an Opportunity object in SFDC for each donation with Payment_Type__c == 'Recurring'
. So it's still just donation
events we need to worry about in basket. The other donation event types seem to all deal with updating an Opportunity to indicate it was canceled for some reason.
Pmac is correct.
Based on this comment the value could be the string "None"
. What should basket record in that case?
Can Basket record "none"? The field in Salesforce is text 25. I'm assuming this scenario would happen with Braintree processing Paypal as those transactions don't have a card type. Subscription Services wouldn't have designed for this since they're taking only Stripe right now.
Yeah. Letting whatever value it is pass through is the easiest thing for me for sure :)
I can change it to the string Unknown
instead, so that it lines up with the value that braintree has for credit cards in general, but I figured as long as it's a string, pass-through should be all that's needed =)
(MoFo work tracked here)
We need to capture credit card type in donation opportunity records so that we can include it in emailed receipts to donors. It sounds like we need to
a.) add the
Credit_Card_Type_c
field to the donation opportunity record type so that MoFo users can see the value. b.) record the type when passed to Basket. I'm not sure if it needs to be a new key in the Basket payload or additional options for payment method, and I don't have an opinion. But whatever key we use should be able to not exist or be an empty string (or null?) like other optional fields already are.