I'm working on Paypal integration using paypal/Checkout-PHP-SDK, and I didn't understand the difference between Set Up Transaction & Set Up Authorization ?
The two are creating an order and waiting for capture but what's the difference ?
An authorization transaction is a type of transaction that authorizes the funds availability at that moment, but does not capture. The capture can be done later, and may or may not succeed.
(Capturing will almost always succeed within the first few days, called the authorization's 'honor period'. Within the rest of the first 29 days, it may succeed and is roughly equivalent to a new transaction being attempted. After 29 days, authorizations expires.)
You can reed abut authorization and capture here: https://developer.paypal.com/docs/admin/auth-capture/
Never use authorizations unless you have extremely specific and well-defined business reasons for doing so.
Related
I would like to create a token (asset) on the Ripple XRP ledger.
What transaction type does that?
So far i only found that a wallet called https://www.theworldexchange.net/ supports that activity.
However, i'd like to do it directly on the network. (Ie through a direct transaction)
There is a complete tutorial (published this August) on how to do this here: https://xrpl.org/issue-a-fungible-token.html
The short version is that it's several steps:
You enable the Default Ripple flag on your issuing account by sending an AccountSet transaction with the appropriate flag. This will allow users to swap your token among themselves.
A user sends a TrustSet transaction to your address indicating their willingness to hold your token.
You send the user the token using a Payment transaction.
There are many ways to use tokens on the XRP Ledger, including community credit, but if you are planning on providing a high-quality token for sales to the public, there are a lot of non-technical steps like defining the appropriate policies, establishing a reputation around your token or your business, and (depending on how you use and promote your token) acquiring the appropriate legal licenses or other standing for the jurisdictions you operate in. (In short: Please don't just make a token to cash in on some online craze and then find the SEC knocking at your door shouting that your token fails the Howey Test.)
You can also create a token through the "Token creator" xApp inside the XUMM wallet.
So you would have to download the XUMM wallet app, create and fund an account and open the "xApps" section and find the "Token Creator" xApp which guides you through the process of creating a token on the XRPL.
Issued Currencies are done via OfferCreate transactions.
In order to issue a currency, one just issues an offer to sell a quantity of some new token for some amount of XRP (or other issued currency for that matter)
What HTTP status code would be suitable for this purpose? The scenario is "I cannot let you evaluate a product because you have already done it". I was thinking about forbidden 403. Is that right?
I would use 402 Payment Required. Even though it's not widely used, I feel like it's perfect for this use case.
402 Payment Required
Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, as proposed, for example, by GNU Taler, but that has not yet happened, and this code is not usually used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests. Sipgate uses this code if an account does not have sufficient funds to start a call. Shopify uses this code when the store has not paid their fees and is temporarily disabled. Stripe uses this code for failed payments where parameters were correct, for example blocked fraudulent payments.
Source
use 405 Method Not Allowed - Meaning - The request method is known by the server but has been disabled and cannot be used. For example, an API may forbid DELETE-ing a resource. The two mandatory methods, GET and HEAD, must never be disabled and should not return this error code .
When using PP Express, its not clear to me until when an authorization has to be used (with DoExpressCheckoutPayment). Is this the mentioned three days time frame?
If I want to use the authorization only later (with all the risks), can I just try my token or do I need to use the Auth&Capture call as described here ?
Seems I did not get what additional benefit I get from DoCapture.
Edit: To make it more clear, I am looking for differences in timing between these workflows:
Express Checkout:
1. token = SetExpressCheckout(..)
2. GetExpressCheckoutDetails(token)
3. DoExpressCheckoutPayment(token,..)
Express Checkout w/ Auth&Capture
1. token = SetExpressCheckout(..)
2. GetExpressCheckoutDetails(token)
3. transactionid=DoExpressCheckoutPayment(token,PAYMENTREQUEST_0_PAYMENTACTION=Authorization,..)
4. DoCapture(transactionid,..)
Can I assume 3/29 days validity for the final Step in both workflows?
(I am using the first workflow successfully already, using up to three days occationally)
Authorization is for merchants who have a delayed order fulfillment process and merchants have to modify the original authorization amount due to order changes (such as taxes, shipping, or item availability) that occur after the buyers place the initial order. For each authorization, PayPal honor the authorization amount for 3 days but the authorization period is 29 days. From day 4 to 29, the authorization is still valid but PayPal cannot guarantee the amount is still available to be capture.
Authorization is set during the SetExpressCheckout and then followed with DoExpressCheckout with same payment action. You can't have the payment action method passed differently using the same token. Each Express Checkout token only valid for 3 hours.Probably you wanted to try out by yourself here?
The Token in the express checkout workflow (1/2/3) is supposed to be valid for three hours.
The workflow with Auth&Capture /1/2/3/4) is to be used if one needs to capture the money only later.
While this seems obvious now, the irritation came from the fact that the token could be used far longer than three hours in my case.
I am working on an application which is going to be heavily dependent on Sabre API. The critical factor for the application is going to be performance when around a million users are accessing the API simultaneously.
After speaking to Sabre API support , all they told me is that they will provide max 50 session tokens at a time and you have to manage sessions at your end.
This leaves my question unanswered - will they be able to handle a million parallel requests?
So basically will we be able to make multiple requests using the same session token unless it expires?
Please help me understand their response.Below is the series of email conversation I had with the Sabre API support.
Hello Karam,
The limit will be the simultaneous sessions that is setup for your PCC. By default you can create up to 50 simultaneous tokens in CERT (50 simultaneous sessions) but the answer to your question is no, processing time from our side will not be impacted.
Regards,
Hello Sebastian
Thank you very much for being with me and helping me out with this.
So as you have mentioned that we can have 50 session tokens at a time, is it possible to make more than 1 simultaneous requests (asynchronous requests) using a single session token?
For example , we get a session token and store it at our end and use it to make multiple requests.
I ask this because , if not , then it would mean we can only make 50 parallell requests at a time (1 request per session token).
And if that is true then we might have to implement a request queue which will delay the responses for the end users.
Thanks
Karam
Hello Karam,
Please see below my answers to your inquiries:
So as you have mentioned that we can have 50 session tokens at a time, is it possible to make more than 1 simultaneous requests (asynchronous requests) using a single session token?
For example , we get a session token and store it at our end and use it to make multiple requests.
It is not possible, It is actually not a Sabre Web Services related behavior but how Sabre host works. Sabre is a synchronous system, once a request has been sent, you need to wait until receiving a response back in order to run a second call. Otherwise you will receive a message like “PREVIOUS ENTRY ACTIVE” or similar.
I ask this because , if not , then it would mean we can only make 50 parallell requests at a time (1 request per session token).
And if that is true then we might have to implement a request queue which will delay the responses for the end users.
It will depend on the session manager and the customer’s needs but most of our customers don’t need to consume 1000 simultaneous sessions. In any case, once you are a webservices subscriber you can define and request to your account executive the amount of tokens that best meets your needs.
Hope this helps!
Best regards,
It is correct, you cannot use the same session/token for multiple parallel requests...(Sabre keeps the session state, and that affects the result of your next request)
What they recommend is to create a session manager, so you'll have your session queue and use them and "ignore" them as you need them. That way you can have sessions for query only and sessions for touching a PNR, you can also manage your own expiration time, or "keep alive" routine.
Our API returns a user auth code which has a session expiry (30 mins of inactivity). So, if we make an api call using the auth token it renews the session to 30 mins from the time of the call.
After 30 mins of inactivity the api returns an error saying that the token has expired. At this point we should request a new auth token.
However, the obvious way to do this (show the user the log in screen and get them to log in again) will mean cutting the user off in the middle of some functions in the app.
For instance, we have various view controllers with options and inputs which aggregate and submit one whole API call at the end of the process. If the session expires on the server whilst the user is filling out these inputs and views then they will be logged out when the API call is made, and they will lose their progress in these views.
There are two possible work arounds for this:
We set timers in the app ourself to make sure the user is logged out after 30 mins inactivity in the app. This means that they won't get logged out during a set of inputs, however this poses the issues that: the server API may still expire even though we are running our own timer. This won't work therefore.
We poll every 10 seconds or so to the server to ask if the API auth token is still valid. This will eat battery, data and all sorts and just isn't a reasonable way to do something like this.
Does anyone have any ideas?
Thanks
Tom
From your description, it sounds like a classic failed transaction problem. Just in case you are not familiar with transaction processing, "Nuts and Bolts of Transaction Processing" is a primer on the topic.
If you have the ability to modify the back end system, you will want to ensure an ACID backend.
This could mean building up data on the client and not send the data to the server until you have a complete transaction. That way, if the session times out, the client still has all the data needed to complete the transaction. (leverage atomicity)
This could mean having a transaction token. As a new session is created the client could send the server the transaction token and the state of the transaction is restored within the new session. (leverage durability)
To me both of these options are better than wiping out the existing transaction and forcing the user to start over again.
Hope that helps.