Comments (9)
And there is only one place on the Internet with details of this error message:
https://github.com/academe/SagePay/blob/master/src/Academe/SagePay/Metadata/error-codes.tsv
Sigh :-(
The XML allows you to override the defaults for the account, so if you are using the same surcharges for all payments, then they could be set for the account. That way you don't need to set each card for every transaction.
I think the validator is good for stuff that changes with each transaction, to catch invalid data from the end user or system that may slip through other validation stages. This is more a configuration issue, and something that would hopefully be caught right at the start when setting up the surcharges for the first time. It does not feel like a data validation error at all, but an API problem that is not documented and is a pretty fatal error that we should not be expected to catch at this end. So personally, I would not spend time validating the XML length, but instead make sure the fatal error returned by SagePay is logged and dealt with.
However, it is worth raising it as a problem with SagePay. I'll do that and point them at this issue. If we can ultimately make the problem go away, then that would be the ideal solution, and that is worth a try.
from sagepay.
Haha yeah I noticed that while google for more information.
In my instance, I'm using the XML to override the default (usually to remove the surcharge for certain payment types), so setting the config in SagePay isn't an option.
Having a validator I think would be useful if only to save someone else the time looking it up - alternatively we could catch the SagePay error and append a link to this issue for the developer.
Thanks for reporting it to SagePay, I had on my ToDo list to find out how to do that!
from sagepay.
Don't hold your breath - SagePay make it extremely difficult to report issues. All the contact details are very well hidden. It has always been this way - I just don't think they realise how it looks to developers trying to use the product. There are some really helpful people on their team, but getting to them is hard.
from sagepay.
Sent the following to [email protected]:
I am having a problem with an arbitrary limit on the SagePay API, and would be grateful if you could let me know who I should speak to about this. I personally think it is an issue with SagePay that could be worth fixing, and can supply more details to the developers if needed.
The issue is this error:
INVALID : 3175 : The Surcharge XML is too long.
This happens if lots of cards are set with percentage surcharges when starting a transaction. The limit appears to be somewhere around 800 characters, and is certainly not long enough to support the number of credit card types that SagePay supports. It is not documented, so it caught us by surprise.
I cannot find a way to raise issues on the admin pages (and I just clicked "CMS Homepage" - aka the "Lock You Out of Your Account" link so am stuck looking any further for a while anyway). Hopefully this email can find its way to the right person.
Regards,
-- Jason Judge
from sagepay.
Okay - Twitter seems to be where they are at - got an quick response there and a new email to send to. Fingers crossed...
from sagepay.
Hello Jason,
Thank you for your email following your Twitter feed.
The Optional SurchargeXML can contain a maximum of 800 Alpahnumeric characters.
Can you confirm the Vendor account you are posting to and we will have a look at the Invalid records; additionally if you could be so kind to also include additional details regarding your suggestion.
Just to clarify, are you also aware that you can set the Surchase via My Sage Pay, and use the XML to override current surcharge settings in My Sage Pay for the current transaction. Percentages and fixed amount surcharges can be set for different payment types (As per to the Protocol guide).
The default cards accepted through the Merchant Acquirer and processed through Sage Pay are:
Visa (Credit)
Visa Debit (Delta)
Visa Electron (UKE)
MasterCard
MasterCard Debit
UK Maestro
Maestro (International)
Option cards through separate Merchant acquirers are:
American Express
JCB
Diners
I look forward to receiving your reply and we will be happy to investigate further.
from sagepay.
I have sent a sample XML file and suggested a few possible solutions, including:
- Extending the length of the field.
- Allowing shorter element names.
from sagepay.
Hmmm, it's gone a bit quiet. SagePay have not said what they are doing with this report. I'll chase it up.
from sagepay.
Just got this back from SagePay. I think it kind of misses the point, but seems to imply that they doubt you will need to apply surcharges to enough different card types for this to be a problem. I don't think there is going to be any movement on this, and it should probably be written down as "that's the way it works and no-one else is complaining about it, so tough".
Please be aware it is currently not possible to apply a surcharges in conjunction with PPRO, that is you cannot currently apply a surcharge to Sofort or GiroPay.
We have been informed by PPRO that they would not expect merchants to apply surcharges to their transactions.
Removal of the surcharge for SOFORT as a payment type as you advised would resolve this 800 character limit issue.
from sagepay.
Related Issues (20)
- Create Omnipay Wrapper
- Make sure typehints are interfaces, not abstracts
- Token field may not be send in server-notification HOT 4
- Helper::formatAmount silently sets Amount to Zero HOT 9
- Fields for Refund not picked out HOT 6
- Switch to PSR-4 autoloading HOT 1
- Start using constructor injection
- Use Data Mapper model rather than up-side-down Active Record HOT 1
- possible misleading information on comment section HOT 10
- Support discounts in basket HOT 17
- Sagepay callback function is not taking sagepay tx_model HOT 2
- Passing correct customer data to Sage Pay HOT 9
- Create Omnipay connector
- Is VPSSignature utilised? HOT 4
- VendorTxCode not guaranteed to be unique or unpredictable HOT 3
- MD5 signature - change from Pending to OK for PPRO payments HOT 3
- Handle duplicate notification callbacks HOT 2
- Second CardType does not contain tamper: true HOT 1
- Support 3d Secure v2 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sagepay.