When trying to submit a Transaction for a Partial Settlement, I'm getting the following exception + message:
Exception of type 'Braintree.Exceptions.AuthorizationException' was thrown.
There is nothing else to explain where I've gone wrong.
This is how I'm making the API call:
BraintreeHandler.Gateway.Transaction.SubmitForPartialSettlement(“transaction_id”, amount);
I know the Transaction Id is correct, because I'm loading the Transaction information beforehand. I'm also always using an amount less than the transaction total.
BraintreeHandler.Gateway.Transaction.SubmitForSettlement(“transaction_id”, amount);
The above works fine with an amount, but I don't want to submit the Transaction for settlement as I'd like to retain the ability to partially settle.
For example: If I have a Transaction Amount of £50 with a status of "Authorized", I'd like to be able to settle for £20, £20 and £10 on three separate occasions. With the SubmitForSettlement() method I can only settle for the initial £20 before the status is updated to "Submitted for Settlement". After this I can't perform any more partial settlements.
Information pertaining to the SubmitForPartialSettlement() method is conspicuously missing from the Transaction docs on the Braintree developer site. Has the method been deprecated? If not, how can I make use of it?
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
SubmitForPartialSettlement is a feature currently being tested and is not available to all merchants at this time. If you would like to request multiple partial settlements to be enabled for your account, please reach out to Braintree support or your account manager.
For the time being, you have the correct solution in SubmitForSettlement, passing in an amount less than or equal to the transaction amount. You will only be able to settle once.
Related
I am installing ecommerce tracking for a pretty simple ecommerce site. I am tracking the conversion on the order confirmation page, recording the transaction ID and order value, and everything's working fine.
However, sometimes the system issues the customer an offer to make an additional purchase on the order confirmation page with a single click (some small accessories that are discounted). If the customer chooses to make an additional purchase, I would like to be able to update the previously sent conversion. I do not want to assign a new transaction ID, because that will artificially inflate my conversion rate. I have tried sending the new amount of revenue with the same transaction ID, however that does not seem to have consistent results (sometimes ignored, sometimes value is just doubled).
I cannot hold back sending the conversion to GA until the customer makes a decision, because oftentimes the customer simply exits the browser without stating whether he is going to accept or decline the offer - in this case no conversion data would be sent at all.
Any ideas? Is there something in the GA library that I'm missing for this situation? Thanks
Nope, there is nothing. Even if a transaction with the same id goes through it's internally treated as a second transaction w/r/t the conversion rate.
If you want to get really fancy you could try and collect the transaction hit on your own server, wait a few minutes to see if you need to add another product and add a queue time parameter to offset for the actual collection time before you send it to Google. While this would work in theory I am not sure it is really feasible in a production environment (and in any case it would probably be more work than it's worth).
I am stuck in a case where Google Analytics is recording multiple eCommerce transaction. We have added code on server side to execute GA eCommerce posting code only one time. Still this issue is reproducible for some transaction. The multiple eCommerce transaction are for same transaction Id but on different dates.
On research I found that this case is with small devices (mobile, tablet). The small devices browser caches whole webpage. And when the browser is opened it reload webpage from cache. So each time user opens the browser and page loads from cache hence the causing this issue.
Can anyone help me on this?
Thanks
"Ignore double transaction ids" would be quite a useful setting and we should try and make this a feature request. However at the moment it does not exist.
The only way I can think of would be to use an API script that selects the transaction ids for the last "n" days and then inserts a heap of filters via the management API to exclude hits with that transaction id. After some time (when the caches have presumably expired) you could throw out old filters. This would be only feasible if you have a small number of transactions (I think there is an upper limit to the number of filters a view can have).
Or if your transaction ids are somehow sequential (e.g. if they contain the date) you might be able to construct a regex that matches earlier parts of the sequence (e.g. previous dates) and only let's a transaction pass if it is higher up in the sequence than the last recorded transaction id (or does not let it pass if the date in the transaction id is lower than the current date - remember to update your filter at midnight).
Caveat: I have not actually tried something like this, but it sounds like it should work.
Recently started exploring the Firebase data via the Data Studio Firebase connector. I'm doing some custom reports based on the user_engagement event to compare with data we previously reported on in Flurry.
When looking at some DAU figures they are pretty close but on MAU they tend to get inflated. (Saw this behavior first on the Firebase Events Report Template). Digging into it a little more we do have a pattern where users frequently reinstall the app which generates a new app_instance_id. So as I fallback I'm using the resettable_device_id but then there's the situation advertising tracking is disabled on device resulting in a zeroed value. (Or for a brief period in January nulled out values, not sure if this was client or part of the Firebase link)
Currently thinking something roughly following the logic below, falling back to app_instance_id if the advertising identifier was not set. What approaches would be worth looking into to have a reliable user identifier for metrics reporting? (In future will be calling the setUserID to utilize our own identifier but looking to match up historical data)
IF(user_dim.device_info.resettable_device_id is not null,
IF(user_dim.device_info.resettable_device_id = '00000000-0000-0000-0000-000000000000', user_dim.app_info.app_instance_id, user_dim.device_info.resettable_device_id),
user_dim.app_info.app_instance_id
) as unique_user_identifier,
Thanks in advance.
Simpler way to deal with the cases where a resettable_device_id is not available:
IF(user_dim.device_info.limited_ad_tracking, user_dim.app_info.app_instance_id, user_dim.device_info.resettable_device_id) as unique_user_identifier
I would look for some feedback on tracking user activity on an commerce website using th google analytics commerce capabilities.
I can't fully understand those 3 parts :
Adding an item (ecommerce:addItem) : obviously when some user add a thing to the cart
Adding a Transaction (ecommerce:addTransaction) : that's where I'm very confused
Sending the data (ecommerce:send) : that's obvious
Can those 3 event append at a different moment ? in what manner ?
What would be a real-world use case that would make you use execute ecommerce:addTransaction and ecommerce:send at a different moment ?
This thing makes me wonder a lot, and I'd like to have some experienced feedback on this as you tend to easily break your stats if something is not done week enough
Thanks in advance
EDIT
So the main purpose right here is to get stats for the pending orders (you add stuff to your cart), and the complete orders (you paid for the things you added).
Right now I only send it all when the order is complete, and things are working pretty good in analytics, but I just don't know anything about the ones that did not complete.
This question was a lack of knowledge.
Simple ecommerce plugin has nothing to do with the enhanced ecommerce plugin
You won't track that much with the first one, except the checkouts. A plain, one order at a time, revenue value.
If you want a deep insight on your users behaviors (when i say deep, I mean it), You have to go for the second one.
We might be able to debate over the unusefullness of the first one; and the fact that its existence in itself compared to the second is completely misleading, as when you first get in, as usual with google, you get flooded by an endless documentation
ecommerce:addItem does not add items to a cart; it adds items to a transaction (with "conventional" ecommcerce tracking there is no cart tracking, you'd have to use enhanced ecommerce tracking. Actually your title refers to enhanced ("ec:") and your question to conventional ecommerce ("ecommerce:") tracking).
So ecommerce:addTransaction starts a transaction; here goes the stuff that affects the transaction as a whole, like transaction id, tax on the total purchase or shipping costs.
Now that you have started the transaction you can add items to it that are associated via the transaction id.
Finally the ecommerce:send command tells Universal Analytics that the transaction should be processed on the server. "send" is actuall a misnomer; addItem and addTransaction do already send data to the server (they each create an request to the tracking server and thus count towards your hit quota).
The reason for this is, as far as I can tell, that the information is transmitted via url parameters (you call the Google Analytics endpoint which returns an transparent pixel). The maximum length for an url request is limited (actual limits depend on browser and browser version).
So the transaction is broken up into multiple parts not because you want to execute the commands at different moments but so it can be transmitted via Url parameters without being truncated. The send command merely tells that you are now finished adding new parts to the transaction and the data can now be processed.
Sorry if the title's a bit vaque, I promise I'll clear it up bellow:
First of all, a while ago I asked a question about selling serial keys :
How can I execute a custom script after purchase with Ubercart for Drupal
The information I posted there may help clear things up in this question but I doubt it much because this question is a bit more general.
Basically, I don't want to execute my custom code until I know the payment has been cleared and the moneys in my account. I was a bit unsure what the conditional action thats trigger is 'Customer completes check out' did though? When it says they completed checkout does it necessarily mean successfully and the money is in my account or not?
If not, how do I make Ubercart wait until it knows I've got the money from any PSP (e.g. Google Checkout, PayPal, etc) to execute my custom code? I can't work it out, is it even possible?
It's not documented or exposed as something that should be reliable but I think that using the 'Customer completes check out' trigger is the way to go.
Bear in mind that the following applies to Ubercart 6.x-2.4. (Latest version as of today)
From what I looked at the code, it seems that the trigger is only executed on successful orders. Whether a successful order means that you have received payment, that depends a lot on your current configuration and the different payment gateways or method you are using, but in general situations and configuration.
That trigger is only launched from one function:
function uc_cart_complete_sale($order, $login = FALSE);
If you do a module-wide search on when that function is executed, it should give you a rough idea on the different situations. Basically I found out that it's being executed from a few payment modules (paypal and 2checkout for example) as well as when you reach the cart/checkout/complete drupal page, which is generally on successful orders. The paypal module, which you specifically asked, seems to be calling that function when a 'Completed' IPN status is received.
It shouldn't be hard to try out a few purchases (right and wrong) and see if your trigger executes only when the order is properly charged.