In the Paypal API, the flow allows opportunity for logging before an API call, sometimes in the middle, such as in the case of Express Checkout, and after a successful payment/transaction. I am concerned about the last step where confirmation of success of the call is received but perhaps was unable to be logged. I've been looking through the API but have not found a way to check the result of a previous payment/transaction. Is there such a call? How do I ensure atomicity in this case?
The DoExpressCheckoutPayment API call is idempotent as of any version > 76.0; you can simply call it again a second time if you wish to verify the transaction really has completed.
Optionally, you can also employ PayPal Instant Payment Notification to get a server-to-server POST with data for each transaction happening on your account.
Related
I need to know how to update UI with the status of a batch update operation. For example i am sending a request to WebApi to update multiple records (could be any number of records), now i want to show the status of each record to client side.
Please suggest me the best way of doing that. I am using WebApi, Angular. I am thinking about implementing SignalR that can update Client UI with respect to the status but is there an another way of doing that ??
signalr may be overkill for what could be a simple polling request to your api.
It's a little ambiguous as to exactly what it is you are doing with your batch update operation, but since your looking to get status back I'm going to assume it's a long slow operation that your not waiting on a response for in the initial request.
Web api has REST principles baked into it from the start so I imagine your batch update operation is using a PUT with a set of objects that need to be updated. If so you could simply request those objects back from your api to check their state and see if the operation has updated them yet.
If your not doing a simple PUT on an entity and it's more like a POST to submit a batch operation you should persist the operation entity and return a reference to it in the initial call then subsequently poll for that operation by id to get its current status.
signalr might let it feel a little more realtime by immediately pushing completed events down to the client but it can also bring a lot more overhead for what you are trying to achieve
I'm looking to implement Google Wallet for digital goods' subscription on my website.
I understand how it works with postback on start and cancellation.
I'm worried if cancellation postback fail contacting my server. As I have a rather large amount of subscriptions, checking manually would be bothersome so I was wondering if there is any way to check subscription state contacting google wallet servers (like Paypal API).
How do you manage failed cancelation postback ?
Thanks,
AFAIK, there is no API to "query" - it would be nice to have :) I recall asking a similar question back in one of Google's developer hangouts about "repurposing" some of the now deprecated Google Checkout API which did have "query apis".
I'd suggest you mitigate things by logging all notifications - aka "notification history". If you experience a processing error on your end, you'd still have access to the "raw data".
Of course this assumes 2 things, (1) Google will never fail sending you a postback, and (2) your server/s are always ready (if they're down, then they can't receive).
Unless I'm corrected by a Googler, I don't believe I've seen a "retry policy" - error on either end - e.g. in GCO API postbacks were resent until the merchant successfully "acknowledges" receipt of the postback. Until then, I think you're down to looking at Merchant Center (manual).
Hth...
I'm integrating a web payment using angularjs.
My main goal are
to let the user be able to topup or pay via paypal
upon successful redirect him back to my site
If the transaction is successful i will then update our db records.
Glad to say that after 2days I'm done with the first 2 steps. Then I've read about using PDT (Payment Data Transfer) and I used this to get the transaction details of the payer but I had read many post saying using PDT isn't reliable enough that I also must use IPN (Instant Payment Notification). So I google about it and almost all sample/tutorial about IPN are made from using server side scripting. So is it possible to perform an IPN listener using javascript alone?
No, not on the client-side. You can use server-side Javascript (nodejs) to do this. The purpose of IPN is to let your server know that a payment is completed. The IPN request comes directly from paypal behind the scenes to a URL you give it. There's no way for a client to receive this signal instead, and if it could then there'd be a big security flaw because anyone could forge it.
However, you could update your backend using IPN, then use something like socket.io (websockets) or long-polling (plain old ajax) to let your client know that payment was successful. With long-polling, you'd basically be asking your back-end every second or two whether or not payment was succesful. With sockets, you have a more direct communication. I like socket.io because it falls back to long polling (or flash) if real web sockets aren't available.
My website on GAE-Python has a function to calculate some math using Evolutionary Optimization Algorithm, which will be called by an ajax request when the user click a button. Each request usually takes very long time to finish calculation.
I need some way (ajax or other methods) to tell the server to cancel the current request rather than using ajax's xhr.abort() function which does not stop the calculation on server side.
For an early attempt, I have found that GAE has the Request Timer in which the DeadlineExceededError will be raised by the runtime if the request takes too long to finish.
Based on this idea, I would like to ask if there is a way to send a signal to the server to cause the runtime to trigger an interrupt on the request?
You shouldn't be trying to do any long-running tasks synchronously in a handler. This is the perfect candidate for a task queue. The Ajax request should simply push the task onto the queue, and App Engine will process it offline. Tasks get a ten-minute timeout.
You can use memcache or the datastore to pass information to and from your Ajax code. For instance, the task handler could check memcache every few seconds for the existence of a 'stop_processing_FOO' key (where FOO is a unique ID generated by the Ajax when the task is first triggered), and the your 'cancel' button would call a handler to insert that key into memcache.
Similarly, the task could put a 'finished_processing_FOO' key with the associated values into memcache when it finishes, and your Ajax could periodically poll a handler that checks if that key is present, and return the value if so.
I am using ndb to write a profiling model that logs some data per application request. Each request calls a ndb request by ndb.put_async to log the data, while the client do not care about the result. In essence, I do not want the application request to wait for saving statistics data for profiling.
However, I was confused about the explanation from the official documentation. If an application request has finished before the ndb request finishes, would the ndb request still be guaranteed to finish? The documentation indicates that
if the request handler exists too early, the put might never happen
Under what criteria would this happen? Does this mean that regardless of whether a user care about the result, future.get_result needs to be called anyway just to make sure the ndb request is performed?
The original documentation (https://developers.google.com/appengine/docs/python/ndb/async) says:
In this example, it's a little silly to call future.get_result: the
application never uses the result from NDB. That code is just in there
to make sure that the request handler doesn't exit before the NDB put
finishes; if the request handler exits too early, the put might never
happen. As a convenience, you can decorate the request handler with
#ndb.toplevel. This tells the handler not to exit until its
asynchronous requests have finished. This in turn lets you send off
the request and not worry about the result.
If an application request has finished before the ndb request finishes, would the ndb request still be guaranteed to finish?
No.
Does this mean that regardless of whether a user care about the result, future.get_result needs to be called anyway just to make sure the ndb request is performed?
Basically yes, but you can use ndb.toplevel decorator for the convenience so that you don't have to wait for the result explicitly. That said, I don't think this is what you want.
Probably taskqueue is what you want. Please check it out.
Thanks for the clarification. What about a general RPC (non-NDB) - e.g., incr_async() in memcache.Client()? Setting aside that this is a very, very fast RPC call, is it guaranteed that the RPC will complete?
I.e., which of the following is true:
(a) there is something in the infrastructure that will wait on all known RPCs before completing the request
(b) the request will complete and the async RPCs will also complete regardless of when the request completes
(c) the in-flight RPCs are formally cancelled
(d) something else?