I'm working on an online store that uses SagePay and I'm currently trying to upgrade the version from 2.23 to 3.00.
I have read through this guide but I'm still none the wiser on a couple of things (and haven't had a response from SagePay in over 48hrs): http://www.sagepay.co.uk/file/10286/download-document/Technical_Guide_to_Update_Sage_Pay_Form_Protocol(2%2023).pdf
The guide suggests that these four fields are mandatory to update:
Transaction Registration:
• VPSProtocol
Sage Pay Response:
• BankAuthCode
• DeclineCode
• ExpiryDate
My problem is that I only use the first field (VPSProtocol) in my whole SagePay integration - does this mean I only need to update this field from 2.23 to 3.00, or do I now need to integrate the other three as well?
If you are successfully integrated at 2.23 using Server or Direct, the only mandatory change is the VPSProtocol value (to 3.00). If you are using Form, you will need to check that your crypt field is AES encrypted (instead of XOR encoded).
The other fields (BankAuthCode, DeclineCode and ExpiryDate) are returned by Sage Pay in the transaction registration response. The main thing is to make sure that your integration can ignore any extra fields without falling over, if you don't want to use that information (you can always get it from My Sage Pay or the Reporting API if you need to).
Update: I should add that when using Server, make sure you are capturing the fields required to generate the signature hash, and compare to that from Sage Pay.
Related
I'm developing an app that uses Square credit card processing API. In the Square web panel, after a charge I see things like "authcode" and receipt number in that interface, but I can't find where the API gives me back this data.
Also, when charging with the Square virtual terminal, I can pace a comment with the charge. When the API makes a charge that comment is set to "online transaction."
So can I have the software leave a comment with the API, and can I get the auto code and receipt numbers through the API?
Not all of the features available in Square Dashboard are available via the API at this time, though we are actively working on expanding the API capabilities, particularly around itemizations and receipts.
You can add external reference_id and note to a transaction if you want to associate some external metadata. Receipts can be retrieved with the older retrieve and list payments endpoints. See here: https://docs.connect.squareup.com/api/connect/v1/?q=receipt#datatype-payment
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.
Need to get started on an upgrade from 2.23 to v3. Is there an easy way to tell whether server, form or direct integration is already being used, and therefore which of the support docs/kits I should be following.
Have a look at the URL you are posting the transaction registration post to. vspdirect-register.vsp for Direct, and so on.
We're attempting to write an application that integrates with SagePay via a web page. The information will be entered by a sales person as part of a larger application (after taking payment details over the phone from a customer) and we are trying to use the Form Protocol Integration to facilitate this.
After having successfully got this working using the PAYMENT TxType, we discovered that the client requires the transaction type of "MOTO". This doesn't appear to work by simply changing the TxType field we are sending (and the documentation is pretty explicit about which types are permitted).
Is there an easy way to resolve this without completely changing the way we're integrating with SagePay? Also, if we do need to use a different API or integration method, is there any documentation on this? None of the documentation I have found has referenced a "MOTO" TxType.
Thank you.
TxType will always be PAYMENT. You can specify the account type with the field AccountType and setting it to M for Moto
Hope this helps.
According to SagePay MOTO can not be implemented for Form Integration. h
We are upgrading our SagePay protocol from v2.23 to 3.0 to support surcharge fees. In v3.0 transaction registration post there are CreateToken and StoreToken which was not in the earlier version. What is the reason for create and store tokens? I went through the document but couldn't find a clue.
The link provided in the above post links to advice by one of our Sage Pay Partners so take a look at it.
Token allows shoppers the option of storing their card details (as a token) to their account on the payment page during their first purchase instead of having to set it up manually afterwards. Single click purchases for repeat customers will become much simpler and quicker to set up.
To view the Token Guide go to here, scroll to the bottom of the screen and select the Download the Documents option within your preferred method of integration (server, server inframe, direct). Within the guide it explains creating and storing a token.
If this is a service you would like enabled on your Sage Pay account our New Business team are available 0900-1800 on 0845 111 4466. Prices for Token are available via here. If you have any other questions, our 24/7 Support team can assist to on 0845 111 4455.
Sage Pay Support.
I believe this is related to their token system, allowing you to store and send card details as a token.
If you don't use their token system you don't need to worry about it.
Sage Pay have destroyed their content recently so it's hard to find anything, here's a quick article on their token system - http://www.metakinetic.com/blog/2013/09/sage-pays-token-system-and-advancements-in-payment-gateways/