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.
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)
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.
We are in the process of replacing our Paypal SOAP API calls (SetExpressCheckout etc.) with the Paypal REST API V2.
Three questions:
1) Paypal has two similar APIs: orders and payments. Which one is considered to be the replacement for SetExpressCheckout?
2) We use the tokens returned by SetExpressCheckout to do a capture or refund later. Can the tokens we got from SetExpressCheckout also be used to do a capture / refund using the REST APIs? (If not, we cannot do a "big-bang" migration, but keep both implementations in place until we are sure no capture or refund will take place for transactions which have been issued with the SOAP API).
3) Does the merchant need to amend anything in his profile, e.g. give new rights to use the REST API? For example, we use SOAP API call TransactionSearch, which requires special rights - are those also valid for REST API calls?
1) Creating a v2/order replaces SetExpressCheckout. Capturing a v2/order replaces DoExpressCheckoutPayment. The capture will return a new transaction id that is a v2/payment object, and this v2/payment object id is the only thing that is preserved in www.paypal.com for accounting purposes (the v2/order id is not used for accounting; like an EC token, it is for the payment approval process only)
For the front-end, use
https://developer.paypal.com/demo/checkout/#/pattern/server
[ You mentioned capturing later, so the following won't apply to that particular case, but: if your flow were set up to capture right after approval with the buyer present, then -- once everything about your implementation is working for the happy path -- don't neglect to add support for handling funding source failures, so that if the immediate capture fails due to e.g. the buyer's first card being declined, this is propagated back to the UI and the buyer can select a different funding source right away ]
2) SetEC tokens cannot be mixed with REST APIs for capture
3) Yes and no. If you're using a REST API to search transactions, then what will matter are the permissions of the REST ClientID+Secret you are using. What will be most straightforward will be for the merchant to generate a new REST app in https://www.paypal.com/signin?intent=developer&returnUri=https%3A%2F%2Fdeveloper.paypal.com%2Fdeveloper%2Fapplications with all the necessary permissions, and provide you with that REST App's live ClientID+Secret.
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 .
Would implementing openssl prevent users from changing the button values?
I've researched into encrypting buttons, from hosted to using openssl.
Using hosted buttons would provide security at the cost of flexibility although there are variables that you can override, but still you cant override the important ones.
would using and implementing openssl on my webserver prevent users from changing a non-hosted paypal button ?
or would it just be better to fall back to a hosted button and use/validate using IPN?
My answer is non–PayPal specific (applies to any kind of HTTP form input), but the short answer is no. Even SSL cannot prevent the browser from modifying the form values that it receives.
A user could use a bookmarklet to execute a JavaScript program of her choice on your page after it has loaded, which has the ability to change form values. Because SSL only protects the transport between the browser and the server, not after the page has been processed by the browser, it makes no difference at all whether you use it.
This could be automated with Greasemonkey, which is the same idea, except makes it even easier for users to install other people’s JavaScript programs to run on your web page. As above, using SSL does not affect this at all, because it is all execute client side, which you, as the server, have no control over.
As you alluded to, using encrypted PayPal buttons would solve the problem, as any modification of the button parameters would invalidate the checksum, and PayPal would not accept the item.
The best solution would be using Express Checkout. This allows you a great deal more flexibility than standard buttons can ever offer you.
If you're thinking if doing IPN, you're probably capable enough to integrate Express Checkout. All it really is, is 1 API call, followed by a redirect to PayPal, and a minimum of 1 more API call to finalize the payment.
A typical flow would look as follows:
Call the SetExpressCheckout API. If you're new to this, it's made dead-easy with PayPal's NVP API interface. You can just send the data as a GET NVP string to https://api-3t.paypal.com/nvp and get a response back in the same format.
Take the token from the response, and redirect to https://www.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=XXXXXXX (https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=XXXXXXX for Sandbox testing)
As soon as the buyer is returned, PayPal will append a PAYERID to your RETURNURL. If you can't find it, call the GetExpressCheckoutDetails API and supply your token to retrieve it.
With the PAYERID and TOKEN, call DoExpressCheckoutPayment to finalize the payment.
To get started with this, I'd suggest taking a looking at the PHP NVP SDK they offer at https://www.x.com/community/ppx/sdks#NVP