Yes (and I realize it automatically fixed it here, but you got me 😉

Yes, the email comes from Stripe, but there is no way for us to fix that on our end – that part of the email is not customizable (I was hoping, but unfortunately… I have a ticket in with them as well because I am assuming it’s something with how their system is rendering it).

I figured the easiest way to deal with it more efficiently, regardless, would be to just get rid of the quotes in the initial communication, which are unnecessary anyway. 🙂

Now it’s showing:

Booking for \’Fab Faux\’

In the payment screen. (For some reason I don’t get any emails from Stripe when it’s in testing mode so I don’t know what they are returning until I hear from her when it’s live)

So… this is what they came back with:

I did some digging and was able to find the source of the problem. The statement descriptor needs to be a plain text. So if you go to your ‘Payments’ tab on your Dashboard, and click on any given payments, you will see the ‘Statement Descriptor’ reads (Booking for 'Fab Faux'). If you scroll down to the ‘Events’ tab and click on the data, it will pull up the codes in the API for that payment. Scroll down to the ‘Descriptor’ line, and it reads (Booking for 'Fab Faux'), so you need to apply to the API whatever you wish but in text form. For example, if you want for it to read just your company name just write out your business name with out coding it.

It sounds like they aren’t going to change anything on their end and want whatever goes through to be passed through with plain text (I’m going to still press them to change this for the future – if every other payment system does it, then it is just stupid that theirs doesn’t).

However, I now have a way to see if it’s passing through as the HTML entity – as he pointed me to where I can look at that on the back end of stripe while testing. So if we want to try anything else we can and I can see what it returns. It looks like the last one I submitted, that had the \’ still went through as html entities :-\ So I guess getting rid of the quotes altogether is the best idea. Do you have a suggestion for me to do that?

And the html entities still didn’t show right (was hoping the code would help with that – oh well)

So with this, it’s just “Booking for” in the popup payment form (the name is blank), and then it’s STILL passing the html entities in the backend for the description. 🙁 Is there somewhere else that might be passing that data?

Argh – yeah I figured. I am pressing Stripe to look into it and fix it, and told them all the cool kids are doing it ;P

I’ll have to take a look at this in a bit – working on some other client work right now.

Thank you so much for your help, it’s always appreciated!

Ah – so… that changed the form popup, but the part that is sending through to the system is down on 849 where it is setting the $booking_descr variable… I just removed the quotes from that and it had an effect.

I looked up “esc_attr” and it looks like that function converts to HTML so that might be what’s doing it?

Stripe helped get me a copy of the receipt delivered to my email and it looks like it’s coming through perfectly with this code.

Yes —-

Line 375 (and 376) are now (this and the following line seem to pass the quotes and name through to display on the form properly):

      $name = eme_esc_html(sprintf(__("Booking for '%s'",'events-made-easy'),$event['event_name']));
       $name = preg_replace('/\'/', '', $name);

Line 401 (I don’t know if this is necessary – I didn’t test it without, but since it was working I left it):

data-description='$name' => data-description=\"$name\"

Line 849 (this successfully sent through the quotes to the backend and then to the email):

$booking_descr = sprintf(__("Booking for '%s'",'events-made-easy'),$event['event_name']);

Yep! I just got a chance to test it out, and it looks like that’s the only line that needs to be changed. Everything else works perfectly. 🙂 Thank you so much for your help!