VendorTxCode not set about sagepay HOT 6 CLOSED

I was wondering why I never saw this problem, and it is because I save the transaction before sending the registration to SagePay. Doing this will have the same effect, as saving will generate a venderTxCode, since that becomes the primary key of the stored transaction:

$server->save();

from sagepay.

I'm inclined to put $this->save() right at the start of sendRegistration()

The registration result is saved after the event anyway. I don't think it is a big overhead to save it before sending to SagePay, which will also serve as a record of what was about to happen, in case the process fails before getting a response.

That should do the trick. What do you think?

from sagepay.

I'd agree with saving it at the start of sendRegistration(), I quite like that the library handles all the saving/loading and it's not something you need to worry about. So to keep it inside would keep it that way.

from sagepay.

I agree. It gets saved anyway, so an extra save will do no harm.

If you have other places or methods you want to save the transactions to, then just extend the TransactionAbstract and add your own saving/loading method in there. That should make it easier to integrate with other systems. You could, for example, save the transaction as a document in a NoSQL database - it does not have to be relartional - or as a post type in WordPress with all the fields serialised into the body, or split up into separate metadata. The flexibility is hopefully there.

from sagepay.

Okay, done.

I remember why the save was originally left out of there: the ability to not save a failed registration was an option that could be set. This would help cut down on the number of failed registrations in storage. Note that these are failures related to invalid data (e.g. a "&" in a postcode or an address line too long, or a name too short) and not failed authorisations (those come later, after the callback). So long as the application validates the data to be submitted before attempting to submit it, then this should not be an issue.

Note that most SagePay gateways do not involve decent validation. I can break most shops using SagePay with a few choice characters in an address field. My intention is to build a validation layer into this library so that data can be checked before it is posted to SagePay. The metadata defining the validation rules is already there, but it is not used yet.

I'm rambling! Shut up Jason :-)

from sagepay.

Actually, I've just realised you are working on validation already. It looks great. Check out the rules in https://github.com/academe/SagePay/blob/master/src/Academe/SagePay/Metadata/Transaction.php as all the fields have very strict validation rules, especially wrt what characters are allowed in them. The rules are defined in "SagePay speak" so will need some simple transaction to regexes and other more standard rules. It is annoying having fields like postcode being mandatory for some countries that don't have postcodes, for example Northern Ireland, for SagePay v2.x at least. And then when the user enters "N/A" the transaction gets rejected with "bad data" because of the "/" in the postcode.

The fact that SagePay will stop dead at the first error it finds, makes so much more important to validate at the application. We may also be able to do some simple transforms to avoid bugging the user (especially if there are multiple payment gateways, all with different validation needs). For example, silently strip out invalid characters in postcodes, truncate address lines that are too long.

Note also that most of the fields are sent to SagePay as single-byte ISO characters, so lengths are in characters or bytes after conversion from UTF-8, which is the assumed application characterset. However, some of the newer XML-based fields may be able to accept UTF-8, but I have not played with them much.

from sagepay.