I'm pulling transactions from Authorize.Net through the transaction reporting API for a customer (I don't have access to their dashboard). Yesterday, I was able to pull about 85 transactions through the GetUnsettledTransactionList call. Today neither the GetTransactionList, or the GetUnsettledTransactionList calls will pull the those transactions. They pull other transactions, but not the ones that were in an unsettled state as of yesterday.
I'm guessing they've been settled, but not able to be pulled from the API, yet. Is there a state in which the transactions will reside where they cannot be pulled by either endpoint?
Yes. This is exactly the case. There appears to be a window of time once a transaction is settled where it cannot be retrieved by the transaction reporting API.
Related
If a server is already listening to Real Time Developer Notifications what’s the benefit to also poll the Voided Purchases API?
The docs say:
Note: Unlike other order-related data sources, the Voided Purchases API includes purchases that are charged back by payment processors. Therefore, you might see inconsistencies between the information from this API and information from other order-related data sources.
This is too vague to draw any conclusions. Does that mean there are scenarios in which a subscription is invalidated which doesn’t trigger a RTDN and is only visible in the Voided Purchases API?
Google Developer Support clarified that the Voided Purchases API is only an addition for investigative / preventive purpose to counter refund fraud. For example, a user who subscribes and after a short time triggers a charge back, therefore having used an entitlement for free.
The API is not required to track subscription state, as a refund (like any other cause) triggers a RTDN.
You may use the Real Time Developer Notification (RTDN) to track any changes on the status of the user's subscription entitlement. Please note that the subscription is immediately revoked when the purchase has been charged back, you can refer to this link for your reference.
Additionally, you may still use the Voided Purchases API as part of your double security, and track the user's behavior to prevent refund abuse on your app.
The Amazon MWS Reports API has an Acknowledged parameter available for returning all outstanding orders that have not been previously acknowledged by the merchant.
So far I haven't been able to find an equivalent parameter that I can use with the MWS Orders API, so I have to work my way through the past 30 days worth of orders using the ListOrdersByNextToken call(s), which come with a fairly severe (and apparently incorrectly documented) call threshold and refresh limit. I'm really hoping I've missed something in the documentation and/or the schemas about acknowledged vs. unacknowledged orders with the Orders API. If this is the case I'd certainly appreciate it if anyone could point me in the right direction.
Right now I'm leaning towards trying the LastUpdatedAfterparameter instead of the CreatedAfter parameter, but I'm absolutely certain the former will always retrieve all new and unshipped orders from the Amazon Marketplace.
It's possible to acknowledge individual orders by sending Amazon a _POST_ORDER_ACKNOWLEDGEMENT_DATA_ XML feed or a _POST_FLAT_FILE_ORDER_ACKNOWLEDGEMENT_DATA_ tab delimited feed however, there's no way (as far as I can tell) to solely pull unacknowledged orders using the Orders API.
You can schedule order reports using the Reports API and then pull unacknowledged order reports as you would with other kinds of reports. I think this is probably the closest feature to what you are looking for.
I have a real time web analytics problem to address, and I'm wondering if some of the WSO2 products might be an appropriate solution.
An ecommerce web site shows pages of products to a browser user, and the web site vendor wants to collect details of what products were viewed in a list, what products were selected from the list for more info, what products were put into the basket, and what products were actually purchased - all in real time. I can use web page tagging to generate logging events for the four states (I.e. In list, view detail, in basket, purchased). The web site vendor wants too see results summarized by product and by rolling time band (e.g. Last hour, last 6 hours, last 24 hours, last 72 hours) by the four product states.
As a complete WSO2 newbie I'm hoping somebody can help with some pointers on how to address this. I've been reading about the BAM module to capture events. Is that a good place to start? Also can anybody suggest a good in memory data store to hold the event data aggregated by event type and rolling time period?
TIA
Yes, BAM is more kind batch processing, monitoring and complex engine and using it you can capture data, process and then present. In architectural point of view, the product states that are changed by the browser user will be captured by the web server and publish to BAM server.
A good point to start is learning about data publishing. Once you define the data [in BAM it is known as stream definition] to be published, you can write a hive script to process it and present. You can pump all data to BAM and then you can use hive script to process and store it in the manner you wanted. Later you can retrieve and present.
I have been working on an application that needs to log credit card transactions which is dependent on using an external API. Within my application, I have the concept of an invoice with a total, and a transaction that when successful credit card payment is made, deducts from this total.
This is more of a platform independent question, but I am working with Django, Python and MySQL.
My question centers mainly around the use of transactions when dealing with external API's and how to design your software to handle potential failures. Both Django and MySQL support transactions, so that in itself is not an issue, but suppose the following scenario:
Credit card submitted though the payment API
Credit card is successfully processed
This response is then logged to the database as a payment on that invoice
There is an error saving the payment to the database for one reason or another
What do you do now?
If there was not an API call involved the answer would be clear, rollback the database transaction and raise an error. But having a call to an external API complicates matters, because this is not really a way to rollback on the external API call.
I am interested if anyone has run into this issue (for credit cards, or similar types of transactions) and how they addressed the problem, or in general some approaches for software design in this case.
It's hard to manage this in software. However, if your payment gateway is calling a callback to signify that the transaction is successful, it will presumably log an error if that callback fails to complete, and you should be able to configure it to alert you in that case, perhaps by email. Then it's up to you to rectify the situation manually.
I'm integrating with Authorize.net's ARB API. Authorize.net processes their transactions at a certain time everyday, so when people create a subscription, their transaction is not real time.
I am creating a subscription based model, does their API tell me whether their CC has been processed? Or should I put a delay on the access to my site until they have processed all the ARB transactions that day.
Thanks in advance!
You should be charging their first subscription payment via the AIM API. This will give you instant feedback as to whether or not the payment was good. Assuming it was successful you then can use ARB to create their subscription by setting the start date to be the date of their next scheduled payment.
This serves two purposes:
If the card is bad you know immediately and can have the user provide a new card while they are still on your website. Once they leave your site it gets much more difficult to get them back to correct it.
You can give them instant access without worrying about whether or not their card is approved or not.
FYI, you can use Silent Post to determine the status of payments made via ARB.