Develop Reference

E00114 Invalid OTS Token while creating subscription with payment nonce using accept JS in Authorize.net

I am building an application using accept js and C# SDK of authorize.net. here, i am using accept js token to make a credit card payment over authorize.net and able to create transaction and customer profile successfully. but when i tried to create a subscription with customer profile id and payment profile id, i got "E00040 Record Not Found" error response.
I also tried to create subscription with another token after creating transaction but getting "E00114 Invalid OTS Token" error response.
What would cause authorize.net to return an these errors?
Looking forward for your quick response.

I was having this problem today, although I was doing PHP on the backend instead of C#. I called into their tech support and here's what I found:
Their production endpoints are actually pretty overloaded on server resources compared to their sandbox unfortunately, at least as of Aug, 2018. This can lead to this misleading Invalid OTS Token error, which can also have several other causes. The tech explained to me that if you have a submit button on the payment form that generates the token and then immediately submits the transaction, that you should add some kind of sleep call (on PHP, that's sleep(5);, for instance). We tried and got it to work on 4 seconds, minimum, but only intermittently. He told me if it fails after a 4 or 5 second sleep call, to reattempt that call one more time after waiting another 2 seconds, before you give up and recommend the customer call your call center or use your other support channels.
In the sandbox, they won't care if you're not using the cert.pem file in your transactions. Not so in production -- you need to ensure you've got that loaded. You can get that file off of Github if you search on the official Authorize.Net files.

Google Admin Directory API SDK User Last Logged In Not Fully Accurate

I use the .Net API for managing my organization's users within Google Apps. Within the directory API you can "RetrieveUser". This returns a User object that has a date property of "LastLoginTime".
Google used to separate out their Last Login Time for an account into three categories using the previous api.
last_login_time - the last time you directly logged into a google service using a UI
last_web_mail_time - the last time you logged into gmail.com webmail
last_pop_time - the last time you popped or imap'ed from their server. (indirect login)
In the new SDK, I don't see a specific "How we populate this" comment within their documentation. I'm wondering, and having trouble testing to figure out the rules myself:
How this is populated?
If it is not all encompassing usage that updates this date (usage meaning ANY interaction between the user and their account), how do I get other dates?
I use the last usage date to recycle idle users. Thus I need an accurate representation of what this date is. I've tested, and it appears popping from a google account is not represented within the SDK LastLoggedIn property, even though you need to log in to pop. Thus, any user that pops from the account and doesn't "Log In" could be deleted by accident.
API Reference
Appreciate any help.

These three (And more) properties still exist, just not attached to the "LastLoginTime". If you want to know if an account is truly idle, you'll need to use the Google.Apis.Admin.Reports.reports_v1 API. You can install via NuGet.
After you make your service object (Many stack answers can show you how to do this), usage is below:
UserUsageReportResource resource = _service.UserUsageReport;
UserUsageReportResource.GetRequest request = resource.Get("User#domain.ca", "yyyy-mm-dd");
UsageReports report = request.Execute();
All the interaction dates will need to be searched through, including LastLoginTime, and then take the latest. Each application has different dates all pertaining to when the last time the user did X action.
LastLoginTime appears to be simply the last time a user directly, or indirectly (via device), logged into the Gmail service. This does not include logging in for pop etc.

payment_status in Paypal

I am using Website Payments Standard integration and in PDT I am confused about showing message to customer on return page if transaction fails due to something, but I cant get messages directly as a response from Paypal, rather I get codes. I was thinking to create a function that will take code as a Parameter and return Error Message. I went here and read about payment_status variable. I got confused when I saw same variable can can set to 1 value off 11 at one place and off 3 at another. What exactly it will return in my scenario? 1 off 3 or 1 off 11?
Edit
See that variable under Mass Pay Variables and Payment Information Variables in this link.

The payment_status would be various things depending on the txn_type. That's why they are separated in categories like that. If you get a txn_type of masspay, then the payment_status would only be 1 of those 3. The majority of the txn_type's will have a payment_status that falls in the list of 11 you mentioned. If you're using a standard button you'll typically follow the information under the Payment Information Variables section.
On another note, make sure you're not using PDT to handle any post-payment processing like updating your database, sending email notifications, etc. Even with Auto-Return enabled there is no guarantee the user will make it back to your return URL, and if they don't, that code will never run.
Instead, you should use IPN to handle such processing, which is very similar to PDT except that it happens separate from the checkout flow altogether. As soon as any transaction takes place on your account PayPal's server will POST data about that transaction to your IPN listener URL. The data will be the same as what you're looking at with PDT, but IPN will always be triggered regardless of whether or not the user makes it back to your site.
IPN will also allow you to correctly handle things like pending payments from e-checks, fraud filters, etc. that would need to clear before you deliver the product. You'll get an IPN when the pending payment takes place, and another IPN when that payment is updated to completed, failed, or whatever.
IPN also allows you to automate tasks based on refunds, disputes, etc. It's a very powerful tool, and again, it's definitely recommended over PDT.

How to commit the multiple transactions from different users using concurrency in windows 8?

Any one give me idea behind for committing the multiple transactions at a time in windows 8.
i.e by using concurrency need to commit all transactions at a time .is it possible ?if ok then please give me idea for implementation in windows 8.
EDIT:
Mulitple transactions are coming from different users at same time then i need to commit all these transactions at a time to server.in windows 8 there is concurrency update mechanism.like that i need to commit all those to server.please tell me idea on this.
Thanks in advance.

You have a database server accepting connections from various clients, and you want to synchronize them so that they are all treated as one big database transaction. I don't think this can be done in a straightforward fashion.
You need your clients to save their data to an intermediary place (say, an "about-to-be-saved" table), and then once in a while, depending on what you define as 'at once', move data from the intermediate table to the "really-saved" table.
You could implement this transaition from about-to-be-saved to really-saved inside your database, so you don't need an additional server.
Keep in mind, though, that giving multiple clients direct access to your database is almost never a good idea.

So, this is tricky. Your question title makes this sound like a database question. Of course without ADO.Net in Windows 8, transactions don't come up a lot in forums. But what you want is the request of multiple users to be processed as a single, atomic action.
Let's see. There are lots of ways to do this. But let's pretend you have a service with two methods. AddToQueue(request) and CheckStatus(request). These two methods would virtually create a transaction for you. Something like this:
Scenario 1 (nothing goes wrong)
User A uses AddToQueue(), adding his request to add $1 to bank
User B uses AddToQueue(), adding his request to add $2 to bank
User A uses CheckStatus(), to see if his request is complete, it is PENDING
User C uses AddToQueue(), adding his request to add $1 to bank
Let's pretend that three items in the queue triggers the transaction to occur
The system batches the 3 existing requests, executing in a transaction
The system flags the requests as SUCCESS
User A uses CheckStatus(), to see if his request is complete, it is SUCCESS
User B uses CheckStatus(), to see if his request is complete, it is SUCCESS
User C uses CheckStatus(), to see if his request is complete, it is SUCCESS
Scenario 2 (something goes wrong)
User A uses AddToQueue(), adding his request to add $1 to bank
User B uses AddToQueue(), adding his request to add $2 to bank
User A uses CheckStatus(), to see if his request is complete, it is PENDING
User C uses AddToQueue(), adding his request to add $1 to bank
Let's pretend that three items in the queue triggers the transaction to occur
The system batches the 3 existing requests, executing in a transaction
The system flags the requests as FAIL (for whatever reason)
User A uses CheckStatus(), to see if his request is complete, it is FAIL
User A retries using AddToQueue()
User B uses CheckStatus(), to see if his request is complete, it is FAIL
User B does NOT retry
User C uses CheckStatus(), to see if his request is complete, it is FAIL
User C retries using AddToQueue()
User D uses AddToQueue(), adding his request to add $1 to bank
Let's pretend that three items in the queue triggers the transaction to occur
The system batches the 3 existing requests, executing in a transaction
The system flags the requests as SUCCESS
User A uses CheckStatus(), to see if his request is complete, it is SUCCESS
User B is no longer active in this scenario!
User C uses CheckStatus(), to see if his request is complete, it is SUCCESS
User D uses CheckStatus(), to see if his request is complete, it is SUCCESS
Make sense? That will work just fine.
Of course, there is more to think through. But that's the basics of it.
Best of luck!

subscribing takes too long for users to wait on webpage for confirmation... solutions?

On our .NET 3.5 website in c# a user clicks submit on our webpage, they are subscribed by email address to our reports. Unfortunately, this action takes about 5 minutes and the user has to sit and wait for confirmation. What I would like to do is change it so that when they click submit, they get a pop up that says they will be notified by email when their subscription goes through, meanwhile i would queue up the subscribe action somewhere else on the server so that it doesnt exist in the web code. Can you give me some ways to do this? The basic idea is that I want to split into two different lines of execution where one will allow them to still browse our website and the other will subscribe them. I was thinking split into a new thread but I think that the web code would still have to wait for that thread to finish before they could do anything else. I'm looking for ideas, preferably something that can run on the same server. thanks!

There's many options, but the basic approach will be to decouple the site from the provider. Instead you'll write out a record saying "User X is waiting to subscribe", a seperate process will then read the record and perform the actual subscription, while marking the record as "in-progress". Once the process has complete the record will again be updated with the completed information.
You can achieve this with databases, message queues, or other approaches. But fundamentally your site will only be responsible for creating the record and checking it's status--the actual interaction with the provider will be handled separately.

If you have something that takes this long and you want to true and ensure the action goes through, then your best bet is going to be to queue it up.
Basically, when they submit the request, store that in a database table and let them move on. Meanwhile, have another process that monitors that table to process the requests. When they come in just have this second process send the request on to the part that takes 5 minutes to complete.
Once it finishes, send them a "welcome to such and such email list" message. That will serve as their confirmation that it worked.

Jeff Atwood blogged on a relevant topic here a while back. Since you are using c#, I assume you're using ASP.NET and can take advantage of the cache mechanisms to kick off a periodic worker job. On the user's request, you can persist details of the subscription to some data store. In that job, you can examine the queue to determine what subscriptions need to be created and then execute them.
https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/