How to capture fields on Checkout Confirmation form that will post offsite?

[neekfenwick]

We're running ZC 1.5.5 on PHP7.3 with the very old SagePay Form payment module, which sets up the Checkout Confirmation page with a form whose 'action' points to the sagepay server, so when you click Confirm Order it will immediately post the data to the sagepay server and not via our own server.

This may be a silly question but wondered what ideas people might have. We want to add a field to the page which would capture the customer's "signature", because we've had trouble refusing a customer refund before because despite having Terms & Conditions displayed during checkout the card company says the customer didn't sign off the conditions so they are not binding.

(Just to preempt some replies, I do understand that most websites don't do this, and I really don't want to have to implement this, but our business owner has requested the feature so I have to at least look into it. We may well ditch the feature - I'm certainly hoping that way).

However if we present a textbox on the confirmation page for their name, the value is not sent to our server (because the form posts to sagepay), so we cannot capture it and associate it with the order record. I've had a look at the SagePay specification and cannot see a way to pack the data in the Crypt field as a 'passthrough' that would be sent back to us when the transaction is confirmed.

Just to be clear, of course the customer is logged in at the time and we know their customer record's firstname and lastname, but we would like a way to present an editable textbox so we can be clear that they are signing their name at the point of confirming the transaction. As said, the card company didn't consider them being logged in as binding enough in a legal sense.

The confirmation form looks something like this:

<form name="checkout_confirmation" action="https://test.sagepay.com/gateway/service/vspform-register.vsp" method="post" id="checkout_confirmation">
  <input type="hidden" name="Crypt" value="@...long_crypt_string...">
  <label>Confirm your name associated with these agreements <input type="textbox" id="checkout_customers_name" name="checkout_customers_name" value="Initial Name Here"></label>
  <div class="right"><input class="cssButton submit_button button  button_confirm_order" type="submit" value="Confirm Order" name="btn_submit_x" id="btn_submit"></div>
</form>

I can only see two ways around this:

1. Present the editable textbox on the checkout_payment page (the one just before checkout_confirmation), which does post to our server and so we can capture the value entered by the customer.
2. Simply display the customer record's firstname+lastname on the checkout confirmation page in a readonly fashion and indicate that the customer is agreeing that this is their name. I'm not sure how binding that would be legally, given how annoying the card company was last time.

[DrByte]

a form whose 'action' points to the sagepay server, so when you click Confirm Order it will immediately post the data to the sagepay server and not via our own server.

...

I can only see two ways around this:

1. Present the editable textbox on the checkout_payment page (the one just before checkout_confirmation), which does post to our server and so we can capture the value entered by the customer.
2. Simply display the customer record's firstname+lastname on the checkout confirmation page in a readonly fashion and indicate that the customer is agreeing that this is their name. I'm not sure how binding that would be legally, given how annoying the card company was last time.

Correct: you would have to do some sort of workaround that does something that your company's lawyer agrees would be legally binding enough to win your dispute.
Such a workaround could not involve sending it to SagePay, so would have to be done before or after.
Or maybe the company's lawyer has better ideas such as more specific terms and conditions or pre-qualifying the customer via other means, or reconsidering how you position the product so that it is less likely to attract a refund.

[neekfenwick]

Thank you DrByte .. we've decided to do my second option - just display a readonly view of their customer's record name on the checkout page. It's very rare that we have the problem and will see if it helps.

Cheers!

[swguy]

A couple of thoughts on this:

- the checkout confirmation page doesn't have all the form processing logic that the shipping and payment pages have, so if you need input from the customer, it's easier to put it on one of these pages.
- you might display the name right above the place order button on the checkout confirmation page - I have a client who is doing that after some complaints from customers who "didn't realize they had agreed to terms" and it seems to work.

NOTE: By submitting your order, you are agreeing to our Terms (link) .... etc.

[carlwhat]

This may be a silly question but wondered what ideas people might have. We want to add a field to the page which would capture the customer's "signature", because we've had trouble refusing a customer refund before because despite having Terms & Conditions displayed during checkout the card company says the customer didn't sign off the conditions so they are not binding.

credit card companies are the worst... the idea that someone bought something from your store, where you have posted terms and conditions, and the credit card company says the customer did not sign off on it is patently absurd IMO.

a couple of thoughts:

• digital signatures are not worth the paper they are printed on.
• as part of the checkout payment, there is a checkbox to agreeing to terms and conditions. is that enabled on your site? does someone need to check that to check out?
• one could implement a pop-up (or other user interface) upon reaching your site, requiring agreeing to the terms prior to entering the site.
• something similar to the cookie consent policy now required by the EU, as defined by the GDPR.

[rant]
the responsibility for fraud on credit cards, almost exclusively lies with the merchant. assuming this is NOT a fraudulent transaction, and that your terms and conditions pass a legal muster, the idea that someone bought something from you but the cc company says they did not agree to the terms is absolutely ridiculous.
[/rant]

[dbltoe]

carlwhat. Your second option was what I thought of when I first saw this. https://docs.zen-cart.com/user/admin...kout_procedure.
We use it on a lot of our sites.

[DrByte]

@carlwhat and @dbltoe, note that the OP stated in first post that they have the T&C checkbox enabled.

[neekfenwick]

@carlwhat and @dbltoe, note that the OP stated in first post that they have the T&C checkbox enabled.

Yes, and thank you to all responders, @carlwhat I especially agree to your points raised. We do show the T&C checkbox on the payment page, and that page does submit to our server. On the final checkout confirmation page we display a bunch of further agreements specific to our products (depending on the product we try to protect ourselves with disclaimers like "the colour of the product may not match the colour you saw on your monitor" and several other cases), which must be ticked before the javascript allows the customer to click the final Submit button. Despite this the refund was refused. I'm not intimately familiar with the payment dispute, my info is second hand so it's a bit hard to really know what needs changing.

My mistake while testing the new 'customer signoff' textbox was that I usually test using a 'direct bank transfer' payment option because it's simple, and in that case does submit to our server. However in the real world 95%-ish of our customers checkout using SagePay credit card payment which submits off-site .. so I was bitten by my own lazy testing methods during development :)