Opened 9 years ago
Closed 4 years ago
#1074 closed defect (bug) (reported-upstream)
Gracefully handle unrefundable ticket refund attempts
Reported by: | iandunn | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | WordCamp Site & Plugins | Keywords: | good-first-bug needs-patch |
Cc: |
Description
CampTix allows users to refund their ticket purchases, but PayPal only allows refunds within 60 days of the ticket purchase.
We should add some logic to the PayPal addon to short-circuit the refund process if the ticket was purchased more than 60 days ago, and show the user a friendly error.
Attachments (2)
Change History (12)
This ticket was mentioned in Slack in #meta by netweb. View the logs.
9 years ago
#4
@
9 years ago
- Owner set to iandunn
- Status changed from new to accepted
This looks really good, thanks Saurabh :)
Instead of returning false
, what do you think about returning a WP_Error
with the message that the refund has expired? Then, form_refund_request()
can check if the returned value is an WP_Error
or not. If it is, then it'd use that error message, and if not, it would use the generic error.
As far as the current path goes, the only big thing I would change would be to modularize the logic that determines if a transaction is refundable, and then just call that method, instead of building it all into the refund method.
Modularity helps keep things simple, reusable, de-coupled, and unit-testable.
Other than that, I'd just recommend a few minor changes:
- I'd probably do something more like
( $txn_details['raw']['TIMESTAMP'] + $refund_expiry * DAYS_IN_SECONDS ) < time()
, since that'd be simpler and cheaper (in terms of performance) than callingdate()
andstrtotime()
multiple times.strtotime()
accepts a lot of different inputs and does a lot of processing to generate its output, so it's (relatively) expensive compared to lower-level operations. That won't make a noticable impact in this situation, but it's a good habit to pay attention to those things. - Since the expiration time is only used inside the
transaction_is_refundable()
method, it can just be a local variable there, rather than an option that the entire class has access to. That'll make it adhere to the "information hiding" principle. - The error message string needs CampTix's text domain.
- Both
P
s in PayPal should be capitalized. - It'd also be good to
log()
that the refund was rejected because the refund period has expired, so that someone viewing the logs would know the specific reason.
#6
@
9 years ago
- Keywords needs-patch added; has-patch removed
Doh, 1074.2.patch
is great, but I just realized that if we take a different approach, we can provide a better UX.
Right now, this is what the user will experience:
- They see a link saying
Change of plans? Made a mistake? Don't worry, you can request a refund.
- They click on that link and are taken to a form they have to fill out.
- After filling out the form, they're informed that they can't get a refund after all.
It'd be better if instead we told them up front that they can't get the refund. So instead of saying, Change of plans? Made a mistake? Don't worry, you can request a refund
, that message should say something like This transaction is passed PayPal's refund period and cannot be refunded
.
There is some existing logic that we can leverage. camptix.php
has an is_refundable()
function that checks if the payment method support refunds.
So, I'm thinking we can add to that to check if the transaction itself is refundable, and also show an alternate message to the user if it's not.
CampTix_Payment_Method_PayPal
should probably have a transaction_is_refundable()
method that each child class can override. In order to maintain backwards compatibility, it'll have to default to returning true
. If the transaction isn't refundable, it could return a WP_Error
with the alternative message to show to the user.
This ticket was mentioned in Slack in #meta-wordcamp by iandunn. View the logs.
7 years ago
This ticket was mentioned in Slack in #meta-wordcamp by iandunn. View the logs.
5 years ago
#10
@
4 years ago
- Resolution set to reported-upstream
- Status changed from assigned to closed
This ticket has been moved to GitHub https://github.com/WordPress/wordcamp.org/issues/577
Added a patch. A summary of changes:
However, I need advice
also adds another error because $result happens to be false.
So, it seems rather unusable because the second error is confusing:
Should we convert this if statement into a switch statement?
And, should I just continue return false and check for that or create a new status constant in the Camptix class and return that instead of false?