In SetExpressCheckout I have the following values set
'PAYMENTREQUEST_0_ALLOWEDPAYMENTMETHOD' => 'InstantPaymentOnly',
'PAYMENTREQUEST_0_PAYMENTACTION'=> 'Sale'
After a successful DoExpressCheckout, this is some of what is returned
ACK => Success
PAYMENTINFO_0_TRANSACTIONTYPE => expresscheckout
PAYMENTINFO_0_PAYMENTTYPE => instant
PAYMENTINFO_0_PAYMENTSTATUS => Completed
PAYMENTINFO_0_ERRORCODE => 0
PAYMENTINFO_0_ACK => Success
PAYMENTINFO_0_PAYMENTSTATUS -- With InstantPaymentOnly set, will DoExpressCheckout ever return a PAYMENTINFO_0_PAYMENTSTATUS of In-Progress, Pending, Processed or something other than a clear yes or no as to the success?
Basically, since only instant payments are allowed, the only payments that will ever complete will have a PAYMENTINFO_0_PAYMENTSTATUS of Completed the first time around?
ACK and PAYMENTINFO_0_ACK -- Are they linked? Paypal states that ACK "Indicates the Success or Failure status of the transaction and whether any warnings were returned."
Both ACK values will either be Success or Failure? Does that refer explicitly to whether or not the transaction was or will be completed?
Much appreciated,
InstantPaymentOnly blocks non-instant funding sources in buyer accounts (such as echeck payments). This means that you will not get transactions that are waiting on buyer funds movements to complete. But there are other factors which could cause a payment to be pending rather than complete. These other factors may or may not apply to your specific use case, but examples include payments made to you in a new currency which would be held until you decide whether to open a balance in that currency or auto-convert them to your primary currency, or certain fraud filter/fraud detection scenarios.
As for ACK/ACK_PAYMENTINFO_0_ACK, for cases where you are only requesting the one payment (and no additional things like billing agreement signup) I would guess the two statuses will always be equal, but I would advise you to verify with the official documentation.
Related
The 425 "Too Early" status code's description:
Indicates that the server is unwilling to risk processing a request that might be replayed
How is it used in a real world scenario? Examples would be appreciated.
You can use a 425 as an error code to handle idempotent requests.
Real world example: I want a request to my API to send money to someone through some crusty unreliable old banks api. Like 60% of the time the underlying api is fast enough, but 40% of the time clients will time out while waiting. If they retry after a timeout the request could potentially double bill them.
So in my API, I ask the sender to send a transactionId, then when they retry the request, they would resend the same transactionId. On my apis side I'm going to store that transactionId and then start the (potentially long running) money transfer. When the transfer finishes you save the result to the transactionId and then return 200(transferResult) to the sender.
If the client gets impatient and retries then the next web request will see that that transactionId is still in flight and return a 425 Too Early. They can then wait a few seconds and try again getting more 425 Too Early responses until the transfer finishes and you return the 200(transferResult) to the sender.
I know this answer is 6 months late, but maybe that helps understand what a 425 can be used for.
PayPal describes a "Honor Period" that lasts for 3 days after you authorize or reauthorize a payment, up until 29 days after the first authorization. The docs don't really go into very much detail about this honor period though, just that you should capture within it and that you can restart an expired honor period by reauthorizing.
I have 3 main questions:
When does the honor period start/end exactly? Is it an exact 72 hour window, to the second, from when you auth/reauth? Does it roll over at midnight or something instead? If so, what timezone?
What is the preferred/recommended way to determine if the honor period for an authorization has expired or else determine the expiration time in the first place? Authorizations have a expiration_time field which marks the end of the 29 day window that an authorization is valid for. Is there a similar explicit time field for the honor period? Is it simply based on the update_time field on the latest auth/reauth?
Is there a way to reauthorize before the previous authorization expires? Or more specifically, is there some way to ensure that the payment is always in an honor period, and that there is zero risk of some issue occurring because their funds weren't being held for a short amount of time before we reauthorized them?
The honor period begins the moment a transaction is created and generally lasts 3 days. During this time, captures will generally succeed. During this time, the amount is generally reserved on the customer's funding source, which may be a credit or debit card, meaning they cannot spend it on other things. The exact behavior may vary depending on the funding source and the country due to different implementations and local regulations. The exact time at which an unused authorization "clears" from the customer's funding source and is no longer visible on their statement can also vary, and might take 10 days to no longer show up in some cases.
The rest of the PayPal authorization valid period -- a "post-honor" period, for lack of a better term -- begins on about day 4 and lasts until the end of day 29. During this time a capture attempt can still be made, and will succeed if money is available from the funding instrument. Such a later capture is roughly equivalent to the buyer themselves attempting a new transaction that is of type immediate capture, in the sense that they will succeed or fail for the same reasons.
Reauthorizations to get a new 3 day honor period (but which do NOT restart the 29-day authorization valid period) are almost always pointless. From day 4 to 29 just do a capture when you are ready, and forget you ever heard of the concept of reauthorization.
I'm running several batch updates (with about 200 entities each one) and I have a Quantum Leap subscribed to the CB to capture the historical data. It is supposed that each batch update should generate 200 different notifications, but, if I have set a throttle of "1", does this mean I will only receive the first notification and loose the other 199? Is this right? (just watching the QL, it seems to me that I'm loosing many notifications)
Entities are processed one by one during a batch update request. Thus, if you have 200 entities the update in each one triggers a subscription, then you will have 200 notifications being sent.
The throttling effect depends on the case. For instance:
If each entity triggers a different subscription, then they have any effect (as the trottling is evaluated by subscription)
If each entity triggers the same subscription and assuming that all the 200 notifications are send very fast (let's say, less than 1 second) then only the first one will be sent, and the 199 remaining ones will be lost.
In general, we don't recommend to use throttling due to this (and some other :) problems. It uses to be better to implement traffic flow control in the receiver.
My question involves parallel (aka split) payments in PayPal's Adaptive Payments API.
I have been trawling various forums for the last hour (doesn't help that all the www.x.com pages are gone), and am unable to find a clear answer to a seemingly simple question about how PayPal's fixed transaction fee is applied in a parallel payment.
I can boil it down to two scenarios, but which is correct: Scenario A or Scenario B?
Many thanks,
Ollie
Scenario A:
Buyer pays $100 (buyer does not pay transaction fees)
Transaction fees for receivers to split = $100 x 3.4% (variable) + $0.45 (fixed) = $3.85
Seller #1 receives $90, less 90% of PayPal's transaction fees (90% x $3.85 = $3.47) = $86.53
Seller #2 receives $10, less 10% of PayPal's transaction fees (10% x $3.85= $0.39) = $9.61
PayPal transaction fees total = $3.85
Scenario B:
Buyer pays $100 (buyer does not pay transaction fees)
Transaction fee for receivers to split = $100 x 3.4% (variable) = $3.40
Seller #1 receives $90, less 90% of PayPal's transaction fee (90% x $3.40 = $3.06 + $0.45 (fixed) = $3.51) = $86.49
Seller #2 receives $10, less 10% of PayPal's transaction fee (10% x $3.40= $0.34 + $0.45 (fixed) = $0.79) = $9.21
PayPal transaction fees total = $4.30
If I recall correctly, the fee is calculated as Scenario A and then split amongst the receivers. You could always test this out on sandbox to determine which method is used.
So after a few inane form letters being sent to me, someone from PayPal responded to my query with the following:
Thank you for contacting PayPal.
From the two scenarios that you have sent Scenario B would apply for the fees on your Adaptive Payment
Scenario B:
Buyer pays $100 (does not pay transaction fees)
Transaction fee for receivers to split = $100 x 3.4% = $3.40
Seller #1 receives $90, less 90% of PayPal's transaction fee (90% x $3.40 = $3.06 + $0.45 fixed charge = $3.51)
Seller #2 receives $10, less 10% of PayPal's transaction fee (10% x $3.40= $0.34 + $0.45 fixed charge = $0.79)
PayPal transaction fees total = $4.30
Thank you for choosing PayPal.
If this is true, I've advised them to make this clearer in their documentation, i.e. that a parallel payment is treated like a series of completely separate transactions, and therefore a full fixed transaction fee applies to each.
If anyone thinks that my advisor from PayPal has it wrong (it's been known to happen...), please speak!
I always assumed that txn_id sent with IPN message is unique. PayPal guidelines seem to support this idea - https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_admin_IPNIntro
Avoid duplicate IPN messages. Check that you have not already processed the transaction identified by the transaction ID returned in the IPN message. You may need to store transaction IDs returned by IPN messages in a file or database so that you can check for duplicates. If the transaction ID sent by PayPal is a duplicate, you should not process it again.
However I found that PayPal's eCheck payment IPN is sent twice with the same transaction ID. Once during initial payment with payment_status as "Pending" and again after couple days when eCheck is actually processes with payment_status as "Completed".
I want to store both transactions, but still would like to avoid storing duplicates. There is another field in IPN called ipn_track_id and it's different for both transactions, but I can't find documentation for it, except this vague description:
Internal; only for use by MTS and DTS
Anyone else is using ipn_track_id to uniquely identify IPN messages?
ipn_track_id shouldn't be used; mainly because this is for internal use only as stated, and because it's unique for every IPN message.
The txn_id is unique for each transaction, not each IPN message.
What this means is; one transaction can have multiple IPN messages. eCheck, for example, where it will go in a 'Pending' state by default, and 'Complete' once the eCheck has cleared.
But you may also see reversals, canceled reversals, cases opened and refunds against the same txn_id.
Pseudo code:
If not empty txn_id and txn_type = web_accept and payment_status = Completed
// New payment received; completed. May have been a transaction which was pending earlier.
Update database set payment_status = Completed and txn_id = $_POST['txn_id']
If not empty txn_id and txn_type = web_accept and payment_status = Pending
// New payment received; completed
Update database set payment_status = Pending and payment_reason = $_POST['pending_reason'] and txn_id = $_POST['txn_id']
You can find a lot more IPN variables listed on https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_html_IPNandPDTVariables#id08CTB0S055Z
Basically; PayPal will generate a unique seller transaction ID. This tranaction ID may go through various stages before it's 'Completed', so you'll need to be able to handle these exceptions.
As for PayPal's note in the documentation: PayPal may resend individual IPN mesages if it encounters errors during delivery. For example, it's required for your script to return a proper HTTP/1.1 200 OK HTTP status response whenever PayPal POST's the IPN data to it.
If you don't return a HTTP/1.1 200 OK response, PayPal will reattempt sending the same data up to 16 times per indiviudal IPN message.
Note: A seller's transaction ID is different from a buyer's transction ID, since they're two different actions (one debit, one credit).
ipn_track_id is not unique for recurring payments. At least for installment plan it's not.
When customer create the installment plan and if your plan have a first payment at checkout you will receive 2 IPN messages with the same ipn_track_id (Example bellow).
First notification "recurring_payment_profile_created" the the first payment "recurring_payment"
Plan created IPN
[txn_type] => recurring_payment_profile_created
[recurring_payment_id] => I-57UAPHFJ3SBY
[product_name] => Risk-Free Trial
[time_created] => 06:24:39 Aug 15, 2013 PDT
[ipn_track_id] => bdd94fdee935a
First Payment IPN
[txn_type] => recurring_payment
[mc_gross] => 10.95
[shipping] => 0.00
[product_type] => 1
[time_created] => 06:24:39 Aug 15, 2013 PDT
[ipn_track_id] => bdd94fdee935a
Not all IPN messages contain a $_POST['txn_id'], so if you solely check for a txn_id, you may intermittently not log IPN messages where they don't contain this key.
In my PHP API call, i use these fields and store them in my database:
custom=xxxx
(or invoice=ZZZZZZ)
then, when your page receives IPN, it should check (from database) if the custom=xxxx or etc...
IPN transactions are unique, also and transactions that change the payment will generate a new txn_id. For example refunds, so its a good idea to store all txn_id related to a single purchase. As of yet I don't know what transactions other than refunds generate a new txn_id, possibly reversals do too.