Until 2 days ago all my recurring payments (subscriptions, payment plans, basically any autocharge) were working through the Protx gateway fine and now they all fail with the message INVALID - 3014 : The TxType or PaymentType is invalid.

If you look it up on their support site you get the following details:

INVALID: The TxType or PaymentType is invalid.

The TxType field (also called PaymentType in very old protocols) should contain the type of transaction you wish to perform. Values such as PAYMENT, DEFERRED, REFUND etc. as outlined in the VSP System Protocols. Check the protocol document for the system you are using (available here on the support web site) and ensure you are sending the correct value in the TxType field.

Having rang them up they told me that for repeat payments (that is any payment submitted without the 3 digit security code) has to be posted with the TxType field saying REPEAT or it will get retured with the 3014 error message I’m getting.

Whilst they couldn’t tell me what’s being submitted via infusion to cause the error, they did confirm that anything other than REPEAT (in capitals) in this field for a payment without a security code would get this error message and that a) their protocols haven’t changed in some time (suggesting its whats being submitted that’s changed) and b) it must have been submitted correctly previously or it wouldn’t have worked in the past.

Can you do anything to help me???

I hate to sound grumpy but this is the 3rd time this has happened now in 12 months!

In the interim, I also need a workaround, basically if I cant process any membership payments I’m gonna be in deep crap v fast! I’ve got bills to pay dude.

So please can you pass this onto the relavent person and let me know who they are, so I can follow up with them.

Also, in the meantime, unless there’s a quickfix, I’m gonna need all the credit card info for all my active subscriptions asap, so I can process payments. Please tell me who i need to speak to to get this executed immediately.


Dan

This is a big pain.

Here's a manual workaround I've found to work which is fiddly and time consuming but may be worth it for the larger amount invoices until this is resolved.

- Find the date of the original transaction in the contact record. ie the first customer payment

- Log into MySagePay and using a search by date, locate that original customer transaction.

- At the bottom of the transaction is a "Repeat" button - click it.

- Put the amount in the relevant field & submit the transaction.

- If the transaction is successful, remember to "add payment" in Infusion (type - credit card manual) to reflect the payment and prevent the autocharge going through in the future.


Was there a minor update applied last week?

Surely the quickest way to get this working again whilst its being investigated would be to regress the change?

Alasdair

I am having the same problem, everything was fine and then nothing is going through just the error code coming up.
Hopefully the fix for this will be here soon as we are loosing a good amount of money on the rebills.

I just spoke to Sagepay and the guy said that they have been tightening up their protocols. If there is any character that is out of place or unrecognised then it will be rejected. He has asked me to resend a repeat payment to https://test.sagepay.com/showpost/showpost

but how can I do that?

Malcolm

Please view this post for the temporary solution to this problem.

Hi,

It is correct that a TxType of REPEAT must be sent to instruct the Sage Pay system to 'repeat' a payment using details previously stored by us.

It does seem strange, however, that the recent protocol update you mention would have had this impact. Our changes were accross all protocols (2.20 to 2.23) and were to do with the use of illegal characters. We have not made any dramatic changes to any of the values or variables that you pass to us to perform a repeat transaction however we have made changes to the characters you are permitted to pass.

The 'showpost' URL which is mentioned above can be used in place of the 'PurchaseURL' that payment details would normally be submitted to. This would then allow our customer service team to see the values you are passing to us and identify any potential values that might be causing problems.

Please feel free to contact me directly through the forum here or visit the Sage Pay forum where I am the moderator, and contact me there, and I'll endevour to help you fix this issue as fast as possible.

Best wishes,

Joe
Sage Pay

Hi Joe,

Welcome to the Infusionsoft Community and thanks for joining us.

I'm confident with your help we can start to get to the bottom of these occasional breaks in service between SagePay and Infusionsoft.

Kind Regards,
Alasdair

I believe the fix for this issue (sending the repeat transactions to the wrong URL for processing when you have CAA enabled inside of Infusionsoft) was deployed Friday night, Saturday Morning for Protx users.