Hello Rody,

You need to call order.InitializeTransaction() which will assign the order an order number and put it in an initialized state.

Then you can call the Finalize method to mark the transaction as complete once you’ve captured payment.

If you are wanting to bypass the checkout process and move an order to be finalized without taking payment then you need to call

order.InitializeTransaction()
order.Finalize(amount, status)

_orderService.Save(order);

Hey Rody,

If you are familiar with TC then it shouldn't be too much of a leap to get to grips with Vendr's payment provider API as really all we've tried to do is to simplify it and merge some things that we felt weren't necessary, that said if it's not clear then we probably need to look at improving our docs a little and maybe a guide on porting from TC could be useful.

Ok, so the key difference really in Vendr vs TC is that we have just a single ProcessCallback method which is used for any communication to the payment provider, compared to TC which had a ProcessCallback method which was used to finalize and order and a ProcessRequest method which was used for arbitrary communication. The issue I saw in TC's implementation was that things weren't often that clear cut and there are a number of providers that mix these two things up, so in Vendr we just decided to make one method for all provider communication.

Because the callback method can be used for multiple purposes then, the important thing to know about the CallbackResult object is that all of it's properties are optional and you should only return values for a given property when necessary.

• TransactionInfo - Should only be populated and returned when you want to finalize an order with the given payment status. If your transaction isn't finalized due to being canceled or the likes, then don't return transaction info. Returning transaction info is a terminal state and once populated the order is finalized and can't be changed.
• MetaData - This allows you to pass meta data from the payment provider to be persisted in the order object as property values. We expose this collection to allow these properties to be persisted once, rather than the old TC way of resaving an order within the payment provider. In Vendr payment providers you should never need to resave the order. Any data that was passed in meta data will be available from the order.Properties collection.
• HttpResponse - Is useful when you are using the callback method for for client side communication with the provider and also for things like webhook handlers where you may need to return a JSON response or a HTTP status code. By default this will just be a plain OK status, but if you do need to pass data or change the response status, you can populate this to do so.

So with this in mind, in answer to your questions

Scenario 1: In this case, you aren't finalizing your order so you would not set a transaction info. If you wanted to perform the redirect, you could do it with a HttpResponse but the better approach would be to use the cancelUrl that is passed in to the GenerateForm method as this will handle returning the order to a modifiable state.

Scenario 2: For this you would use the ProcessCallback method as a webhook handler and so you will likely need to return a HTTP status to the 3rd party to show that the request was successful. At the same time, you can pass info back in the TransactionInfo object as the order updates and Vendr will automatically finalize the order on the first request, and then update the transaction info on any additional requests to that method, so for example, your first request might finalize the order and set the payment status to authorized, but then a subsequent request may actually set the payment status to captured.

Regarding sending of emails, we send the order receipt email as part of the order finalizing event, however if there are things that are reliant on payment actually being cancelled you may want to instead listen for PaymentStatusChange event and watch for it changing to Captured and then perform your task. We do this ourselves on the actual Vendr store only generating and sending licenses when the payment becomes captured.

I hope this helps clarify things, and hopefully you can see how we've tried to merge and simplify what was a little cumbersome in TC.

Matt

Hi Matt,

Thanks for the clear response.

I think these 3 information blocks about the entities TransactionInfo, MetaData and HttpResponse would be a very good addition to the docs. The part that was a bit unclear for me, was that I am able to send a CallBackResult without a TransactionInfo and that sending any TransactionInfo triggers a finalization of on order, independent of what the PaymentStatus for that TransactionInfo is in the CallBackResult.

Two final questions about this:

1. We currently utilizing the "FinalizeAtContinueUrl" property in our payment provider, but what is the exact consequence of settings this property to true?

2. Is it possible to send a CallBackResult without a TransactionInfo, but only metadata, to save some state of the payment process in the order? For instance when the payment is being checked, we receive a intermediate state from our payment provider. We don't want to finalize the order at that time, because the order is not payed yet, but we would like to save this status info in the order (cart). In TC we would be able to see the carts in the back-end, and our client could track the state of the payment using that cart. When the payment is really finished and accepted, we finalized the order and the Order was created. In Vendr however, in the back-office we cannot see the carts. This makes this process a little different. I am looking for a best practice to handle these kind of situations.

is working on a reply...