Both are fired correctly when paymentis made via Cash (first is fired on order completion and the second upon capturing funds in the back office) as expected.
But, when paying via BrainTree in FastTrack, these events don't seem to be firing although the orders are marked as paid in the backoffice (so payment was successful).
My assumption is that I shouldn't need to fire these events manually in the FastTrack code as this should be handled/fired at a lower level (Merchello PaymentGateway).
Am I missing something or is this a bug introduced in Merchello v2.1 or "by design" and I just need to hook into the FastTrackBraintreeControllerBase.HandlePaymentSuccess code to do what I want on success?
I've copied the Umbraco event handler from a v2.0/Bazaar implementation where the events did fire for brain tree payments - but they don't fire for v2.1/FastTrack.
The log does show the binding on app startup. The log also shows the auth entry when completing a cash order and also the capture entry when capturing the funds in the Merchello back office.
However, when paying via BrainTree (FastTrack), the log does not show either of these events firing.
Am I right in assuming that the events should be triggered from the Merchello code and not from the FastTrack BrainTree code? That is, I shouldn't need to enhance the FastTrack BrainTree code to initiate the auth and capture events?
First, the Braintree Standard Transaction is doing the AuthorizeCapture transaction - which never calls the Authorizing event since it does it in a single transaction to Braintree.
I've added a new event handler named AuthorizeCapturing that is now called. It was actually calling the Capturing which I removed to reduce confusion (although this is technically a breaking change).
I also changed the model passed to some of the events from PaymentOperationData to AuthorizeOperationData since the Payment property in most cases could not be assigned and was always null.
PaymentOperationData now inherits from AuthorizeOperationData to clean things up - this is another minor breaking change.
The following code is what I tested:
/// <summary>
/// Handles Umbraco Started.
/// </summary>
/// <param name="umbracoApplication">
/// The <see cref="UmbracoApplicationBase"/>.
/// </param>
/// <param name="applicationContext">
/// Umbraco <see cref="ApplicationContext"/>.
/// </param>
public void OnApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
{
PaymentGatewayMethodBase.AuthorizeCapturing += PaymentGatewayMethodBase_AuthorizeCapturing;
PaymentGatewayMethodBase.AuthorizeCaptureAttempted += PaymentGatewayMethodBase_AuthorizeCaptureAttempted;
}
private void PaymentGatewayMethodBase_AuthorizeCaptureAttempted(PaymentGatewayMethodBase sender, Core.Events.PaymentAttemptEventArgs<IPaymentResult> e)
{
var attempt = e.Entity;
if (attempt.Payment.Success)
{
var providerName = attempt.Payment.Result.PaymentMethodName;
LogHelper.Info<UmbracoEventHandler>(string.Format("Can show AuthorizeCaptureAttempted fires for {0}", providerName));
}
}
private void PaymentGatewayMethodBase_AuthorizeCapturing(PaymentGatewayMethodBase sender, Umbraco.Core.Events.SaveEventArgs<AuthorizeOperationData> e)
{
foreach (var arg in e.SavedEntities)
{
var providerName = arg.PaymentMethod.Name;
LogHelper.Info<UmbracoEventHandler>(string.Format("Can show AuthorizeAttempted fires for {0}", providerName));
}
}
FastTrack Braintree events
Hey Rusty,
I've registered two payment events for Auth and Capture:
Both are fired correctly when paymentis made via Cash (first is fired on order completion and the second upon capturing funds in the back office) as expected.
But, when paying via BrainTree in FastTrack, these events don't seem to be firing although the orders are marked as paid in the backoffice (so payment was successful).
My assumption is that I shouldn't need to fire these events manually in the FastTrack code as this should be handled/fired at a lower level (Merchello PaymentGateway).
Am I missing something or is this a bug introduced in Merchello v2.1 or "by design" and I just need to hook into the FastTrackBraintreeControllerBase.HandlePaymentSuccess code to do what I want on success?
Cheers, Trevor
They should be firing (can't think of a reason why they wouldn't be). I'll have to run through it. How are you handling the event?
I've copied the Umbraco event handler from a v2.0/Bazaar implementation where the events did fire for brain tree payments - but they don't fire for v2.1/FastTrack.
The log does show the binding on app startup. The log also shows the auth entry when completing a cash order and also the capture entry when capturing the funds in the Merchello back office.
However, when paying via BrainTree (FastTrack), the log does not show either of these events firing.
Am I right in assuming that the events should be triggered from the Merchello code and not from the FastTrack BrainTree code? That is, I shouldn't need to enhance the FastTrack BrainTree code to initiate the auth and capture events?
Trevor - absolutely correct.
It's probably due to the async implementation in FastTrack (was done in JavaScript). In the Bazaar everything was pretty much synchronous.
I think I'll have to do an async await ....
Hey Rusty,
Do you want me to raise this as an issue in YouTrack or have you already done it?
Cheers, T
Hi Trevor,
Yes, please add an issue - I've been working on a big update and I forgot about this one ...
Issue has been raised: http://issues.merchello.com/youtrack/issue/M-1075
Thanks
Thanks Trevor,
The problem was two fold.
First, the Braintree Standard Transaction is doing the AuthorizeCapture transaction - which never calls the Authorizing event since it does it in a single transaction to Braintree.
I've added a new event handler named
AuthorizeCapturing
that is now called. It was actually calling theCapturing
which I removed to reduce confusion (although this is technically a breaking change).I also changed the model passed to some of the events from
PaymentOperationData
toAuthorizeOperationData
since the Payment property in most cases could not be assigned and was always null.PaymentOperationData
now inherits fromAuthorizeOperationData
to clean things up - this is another minor breaking change.The following code is what I tested:
is working on a reply...