search

wirecatllc / blesta-stripe-universal

Blesta Non-merchant payment gateway using Stripe Checkout
MIT License
5 stars 6 forks source link

Transactions table overflows off the screen due to long reference ID #10

Open xboxfly15 opened 3 months ago

xboxfly15 commented 3 months ago

Moved from https://github.com/wirecatllc/blesta-stripe-universal/pull/7

The Blesta admin client profile transactions table clips off the screen because of the long reference ids, and that hides the date and edit button.

My suggestion is to use the email address provided by Stripe and fallback to the ID when no email is provided. (not using real numbers, dont worry) You can also see how the Blesta PayPal gateway does it too, I was using them previously - they use email address. long-reference-ids

What it looks like with my suggested change using-email-instead

I understand email not being as unique but the transaction ID is already provided (That's what the "pi_" number is), which is what Stripe use to identify payments, you can see that by going to your Payments view in the Stripe dashboard.

At least, I don't think the checkout session ID should be used, Stripe doesn't normally provide that(You have to dig around in the events and logs section to find it), they're very long, and Stripe doesn't provide a filter for it which makes them hard to use.

xboxfly15 commented 3 months ago

I had a better idea: Use the customer ID that Stripe provides for someone(they're a number that starts with gcus or cus), they're short enough so they don't overflow and it's unique, plus Stripe provides a filter for customer ID in "More filters" where you can enter the ID to see all payments from that person.

using-customer-id

Looking at this though, it seems the customer ID is rarely populated https://docs.stripe.com/api/checkout/sessions/object#checkout_session_object-customer only if the customer_creation is set to always.. but customer_email is populated so I'm not sure why. If thats due to the webhook being used? It's why I used the customer_email in the first place because its populated else the customer ID can be used instead.

NeverBehave commented 3 months ago

The customer ID should be persist across transaction. Stripe is kinda weird about this. This is also a "bug" I am trying to fix. However it involve persist the ID to the User which i don't really want to add extra database operation, but it should be fairly easy tho.

The idea is if you provide email it will automatically create a new customer in the (stripe) system, as email is not an unique id for Stripe, each email will create a new customer ID.

The refund/void transaction needs the transaction id only, the reference id is actually optional. If we really want to do that maybe just trunk the field.

Also I don't have UI issue shown on your side --- did you use a different theme or external css?

Screenshot 2024-05-01 at 11 24 25 AM
xboxfly15 commented 3 months ago

Yes Stripe seems weird about it. I'm not using a different theme or modified the CSS, so I'm not sure why there's a difference, maybe my font size is bigger or something, with how my browser/pc is setup.

I think the easiest option for now would be to trunk the reference ID or not have any reference ID at all, because it would be unnecessary and hard for us to modify the CSS of the table to accept longer fields. And emails are not unique so cannot use them.

The ideal way would be using the customer ID but Stripe is weird and it would require an extra database operation, which we should avoid if possible.

In the future, this could always be an option that people can change if it ever becomes a problem for some reason, that the reference ID is trunked.

NeverBehave commented 3 months ago

What worries me now is we are fixing a problem in a way that might not be the problem itself and we are breaking an existing field. It sounds like a Blesta UI issue rather than the plugin handles it. If we are "fixing" it now, I think maybe just remove/comments out that field as it is not necessary useful (session id after transaction success/failed?) and avoid further confusion (mixing full and trunk fields)