The billing address being sent by our system used to be visible when the system reached the VPS Form - so that it can be adjusted by the user at the time of entering their card details.
It is no longer visible since Sagepay updated their UI a few weeks ago.
This is leading to a lot of payments being declined which would never have been declined in the past.
How can I force it to remain visible?
TIA
You need to set the template back to Default in My Sage Pay. This will give you the old page, which isn't so great (OK, it's horrible) on a mobile device.
Related
I currently Integrated Braintree ACH. There's no website, It's a single-page module. ACH Braintree takes two days for a trial deposit so we need to hold the page for at least two days. So users can come back and verify and continue.
I'm clueless here, about how to save this state of the process until it's done.
Live link of module:
'Live Link
I'm currently passing an email & shipping address to Shopify's checkout since Shopify doesn't support multiple destinations. So to avoid confusion I use our company's address and prefill the address, while the actual destination addresses show up as a custom attribute of each line item.
This isn't ideal, but its the best we can do with Shopify at the moment, eCommerce isn't very well built for gift giving.
After clicking checkout in the cart on our storefront, they are taken straight to the shipping method selection.
However I noticed a pretty bad problem with this solution, the opt-in marketing is true by default. Since the opt-in is on the first step which we skipped, the customer never sees the prompt and is not aware they will be signed up for marketing emails. I'm no lawyer but that doesn't sound very compliant.
I've dug through the Storefront API documentation and can't find any way to set buyer_accepts_marketing in checkout.
It confuses me a bit why I can set both the email and shipping address in checkout, which skips the first step, but I can't set the marketing opt-in.
Is there any workaround for setting buyer_accepts_marketing before grabbing the checkout weburl?
I was trying to pay for google developer account but I am getting this error
Your request failed. Use a different payment method, or contact us.
Learn more [OR-CCSEH-21]
I tried searching a lot but most of them have answers for [OR-CCSEH-05] but not for [OR-CCSEH-21]
What can I do?
For my Turkish colleague;
QNB didn't worked
Kuveytturk didn't worked
Yapıkredi worked.
This solved the problem for me:
Sign in to Google Pay [https://pay.google.com/]. I noticed that this page is the "parent" to Google Development Account payment, e.g., you can have different payment methods for your personal gmail extra storage and your business google development account. They show up under the "Subscriptions and services" tab. Also, errors seem easier to handle here.
At the top-right corner, select Alerts. This is the "Bell/notification" icon.
If you have a red alert, take care of that. In my case, I have not chosen a Backup payment method in addition to the Primary method.
Refresh the page to make sure there is no critical Alert left.
Go to "Payment methods" tab and "Add payment method". In my case when I entered the card numbers, an old address of me populated in the address and zip code fields. I simply changed that to my legal address and that worked! However, when I did the same action in the google development account payment page, I was getting the [OR-CCSEH-21] (on Safari) or [OR-CCSEH-24] (on Chrome) errors. I could not find where Google is reading the old address from (probably a bug)
I tried Union Bank of India, it didn't worked
I tried State Bank of India, it didn't worked
I tried Andhra Bank, it didn't worked
I tried Axis Bank, it didn't worked
I tried HDFC Bank, it didn't worked
I tried Kotak Bank, "finally that worked".
So my only advice is first keep the details correct and iterate each
and every card you can try, hopefully one card will be accepted
From my experience this is happening because the bank card doesn't support Automatic payment option which is required for auto renewal. If a card with Automatic payment option is provided, the payment will go through.
When I got a card from my bank with Auto payment enabled, it worked for me. The issue started with RBI's (Reserve Bank of India) restriction on Merchants storing customer card details.
Ive built 2 websites using opencart 2 (many more on Opencart 1) and both are setup to take Sagepay Server payments, But its now come to light that both sites Sagepay payments are failing when Sagepay tries to talk back to opencart to give the green light. This means no failure email notification is sent to the store owner, and the sale is cancelled at Sagepay? as you can imagine both store owners are not happy. I contacted Sagepay to see what was happening and they told me the payments were failing with the below Error, but as far as Sagepay was concerned the payments had passed all tests, but because the calling website could not send the correct response back to Sagepay, they had to cancel the transactions!
Looking at how Sagepay works, it seams sagepay returns autorisation to Opencart and then opencart has to say whether its going to accept the payment based upon what is being sent, and it seams this is where opencart 2 is failing to respond correctly?
Is this yet another OC2 bug?
Has anyone come across this and how do I put this right
One site is on OC 2.0.2.0 and the other one is 2.0.3.1
Everything is setup correctly in payment module and IP Address logged with sagepay etc.., its just a problem after payment authorisation.
Transaction completed but Vendor systems returned INVALID or ERROR in
response to notification POST. Transaction CANCELLED by the Vendor.
This is a really big problem, and not sure how to go about fixing this, as Opencart 2 is meant to be able to take sagepay payments out of the box, once a few settings are added in the admin section, but it seams its not setup correctly to do so.. I cant believe no one else has come across this?
I used the built in sage pay debug option which told me it was a MD5 Hash mismatch, after further digging and reading the official Sage pay Server docs, there was a notice in Bold Red, stating to ensure the Vendor name was supplied all in lower case, mine was in title case in the admin section. It looks like the creator of Opencart 2 has over looked this, I simply used php`s strtolower function before the MD5 comparison in the sagepay_server.php controller file to convert the vendor name to lowercase. Of course this could be avoided by entering the vendor name in the sage pay server admin section as lower case. But seeing as there is no note when entering this, opencart should convert the vendor name to lowercase as I have done to ensure no possibility of this error.
I'm using the Paypal 'Express Checkout' option in Magento.
(I'm not using any express checkout buttons, it's just because I was having problem with returning from Website Payments Standard).
In Paypal's Website Payment Preferences, I've set the 'Contact Telephone Number' field to off.
I've also made a number of changes on the Magento side to make telephone number optional
(as per this post).
However, the telephone number field still appears during Paypal checkout, and is mandatory. Obviously, this is potentially going to cause customers to abandon the transaction.
Initial response from Paypal support is that the telephone number is always mandatory, that the preference setting only controls whether or not the value is returned to the seller - this doesn't sound right to me, since it makes the setting largely useless.
Given that Magento usually requires a phone number, I'm wonder if possibly something in the Magento Paypal API call is overriding the default setting?
There must be some way of making the phone number optional?
Edit:
It would appear after further contact with support, and some more digging, that despite the description of the parameter, Paypal will always insist on a contact number for non-Paypal accounts (i.e. paying directly by credit card). This applies for Website Payments Standard and Express checkout at least, possibly more.
The 'Telephone number off' parameter then controls whether the phone number entered is returned to the store.
This strikes me as daft. If I'm on a checkout somewhere and asked to enter a phone number,I don't particularly care whether it's Paypal or the merchant asking me for it, I'm not going to be happy about it and quite possibly abort the transaction, especially if it's for a site I haven't shopped with before. I don't even see why Paypal need the number - if there's a suggestion of somebody fraudulently using my card I'd expect a call from my card company, not Paypal. I'd probably hang up if someone claiming to be from Paypal called me.
Plus given that is the way it works, they could have made it a lot clearer by pointing out the the 'Phone number off' field only applies some of the time
/rant
Have you tried setting the phone number option to 'On (optional)'?