Surcharge XML is too long

[Patabugen]

This isn't a bug in the library so much as an annoyance in SagePay, but you may have some insight which helps.

When sending SurchargeXML there is a maximum length of the XML otherwise SagePay returns:

INVALID : 3175 : The Surcharge XML is too long.

I've not calculated exactly what the limit is (though it's around 800 characters) but there is enough space to set all but about three card types

$surcharge->addPercentage('VISA', $surchargeAmount)
    ->addPercentage('AMEX', $surchargeAmount)
    ->addPercentage('DELTA', $surchargeAmount)
    ->addPercentage('JCB', $surchargeAmount)
    ->addPercentage('DC', $surchargeAmount)
    ->addPercentage('MC', $surchargeAmount)
    ->addPercentage('UKE', $surchargeAmount)
    ->addPercentage('MAESTRO', $surchargeAmount)
//  ->addPercentage('MCDEB', $surchargeAmount)
//  ->addPercentage('IT', $surchargeAmount)
//  ->addPercentage('GIROPAY', $surchargeAmount)
    ->addPercentage('SOFORT', $surchargeAmount);

Additionally using a Fixed amount lets you specify all card types because "fixed" is a shorter word than "percentage".

It'd be good to create a validator to catch this.
If this is indeed an issue with SagePay I'd suggest workarounds are either:

1. Use Fixed amounts always, and calculate the percentage if need be
2. Recognise a few card types you're not going to use.

[consilience]

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.

[Patabugen]

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!

[judgej]

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.

[judgej]

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

[judgej]

Okay - Twitter seems to be where they are at - got an quick response there and a new email to send to. Fingers crossed...

[judgej]

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.

[judgej]

I have sent a sample XML file and suggested a few possible solutions, including:

1. Extending the length of the field.
2. Allowing shorter element names.

[judgej]

Hmmm, it's gone a bit quiet. SagePay have not said what they are doing with this report. I'll chase it up.

[judgej]

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.