Fields for Refund not picked out

[Patabugen]

I don't think this is technically a bug (yet) since the library doesn't (yet) support Refunds. However I'd like it to :)

in the ServiceAbstract is a method queryData() which creates a Query String based on the $message_type, which are things like 'server-registration'.

Correct me if I'm mis-understanding something, but do the picked fields not depend on the transaction type? E.g PAYMENT or REFUND?

My thought is that the TxType should be passed into QueryData and in the Metadata\Transaction object the "source" arrays should be populated by TxTypes.

[Patabugen]

I guess a better question would be:

I'd like to add Refund support, how would you envisage it working? (I've just seen the release() and suchlike methods in shared()).

[judgej]

Hi Sami,

The message type is a slightly different level to the transaction type. Some transactions can have multiple messages involved, each with different fields. A message is a block of data sent to (or received from, IIRC) SagePay, and there is a table in the documentation that describes each of those messages.

[judgej]

In Academe/SagePay/Metadata/Transaction.php the message types are all listed as "source" (as the "source" of each field is a message type - kind of a terminology that came from the SagePay docs).

The three types of messages are "direct", "server", "shared" (both direct and server) and there is also "paypal". So the message type is prefixed by this type to give us message types like "server-registration" (the registration of a transaction for payment, used in the server protocol) and "shared-abort" (the aborting of a transaction in either the server or direct protocols). There is also the "response" suffix that identifies the fields in the response we get from SagePay.

So to create a repayment transaction, first the fields in transaction.php should be identified, and given a "source" to group them together. I expect "shared-refund" makes sense (a refund for both direct and server protocols is possible). That way when the message to request a refund is made to SagePay, it will include only those fields with the "shared-refund" label in the query string of the message that is sent.

Transaction.php is like a list of all possible fields used in all messages, and in the database, with metadata to say how they are formatted and when and where they should be used.

For refunds, the transaction ID of the refund will be a new and unique code like any other transaction. The transaction that it refers to, that it will be refunded against, will be in the RelatedVendorTxCode field. You just need to remember VendorTxCode is the primary key of the transactions entity.

Hope that makes sense :-)

[judgej]

Why refund has got left off, is a mystery to me. It was just of those services that got left to later, I suppose.

[judgej]

Note also in Academe/SagePay/Shared.php that there is a translation between VendorTxCode and RelatedVendorTxCode in some of the messages. This is because in a small handful of cases, SagePay uses the same field name to mean different things. So SagePay will expect a VendorTxCode for a refund (for example, I thing) but we cannot use that field name locally, because it is our primary key, but we translate it to RelatedVendorTxCode (i.e. move it to that field) before storing it in the database, and also translate RelatedVendorTxCode to VendorTxCode in the queryData() method for sending the field to SagePay.

Also just noticed REFUND and DIRECTREFUND services Academe/SagePay/ServiceAbstract.php I cannot remember the difference between the two, but it is something to watch out for. Ah, here we go:

http://www.sagepay.de/help/faq/what_is_direct_refund

It looks like REFUND is for refunding against a transaction, and DIRECTREFUND goes not even care if there was an original transaction or not. Sounds more like just a way to make an arbitrary payment onto a card.

[Patabugen]

Thanks for all the info! In fact I started down a similar route, adding a "refund" method in Shared.php and tagging (under Source) all the fields required for source, as "shared-refund". I also added a few fields which were missing from Transaction but called for in the SagePay Shared Docs.

As I was wrapping up for the day I realised I'd done it a bit wrong, so wait until tomorrow to look ;) I've also based this on an already-merged copy of my repo with all the pull requests in (so I don't know how easy it'll be for you to see).

Basically It's going to work like this:

$server = new Academe\SagePay\Server();
// Set the TxModel and suchlike
$server-> refundTransaction($VendorTxCode, $amount, $description);
$server->refund();

Where the refundTransaction() works a bit like findTransaction(), it creates a new transaction with all the fields set (RelatedTxCode and suchlike), then refund() equiates to sendRegistration.

There may be better names for those functions, feel free to suggest.

The current all-in-one version (which mistakenly starts with you already having a transaction which you don't need to get:
https://github.com/Patabugen/SagePay/blob/features-refund/src/Academe/SagePay/Shared.php#L70