I am fetching the contributing transactions for a given payout token via the Stripe API (PHP). The query returns no errors, and shows 9 contributing transactions, all correct. However, the amounts shown did not add up to the total paid into the bank. I logged on to Stripe itself, searched for the given payout token, and was shown a listing of the transactions - except now there were 11! I've repeated the process a number of times, but each time I only get the same 9 transactions via the API instead of the complete 11 I get on their site.
Can anyone point me towards a solution? Is there some reason Stripe would truncate an API response for a single payout? I cannot see any mention of doing so in their documentation.
The answer lay in providing a 'limit' parameter to my request. It defaults to 10.
Related
I have a problem when trying to use Amazon product API. I have all my credentials, but when I send a request I get a 503 Status code with description
You are submitting requests too quickly. Please retry your requests at
a slower rate
I have tried a library called apai-io link: https://github.com/Exeu/apai-io.
I have also tried this code: https://www.patchesoft.com/amazon-affiliate-api-php#fullcode.
The weird thing is that I am sending only one request, trying to find a product with a specific ID. I would really be grateful if someone could give me some instructions or more information.
They are rate limiting the requests, see the discussion here
https://forums.aws.amazon.com/forum.jspa?forumID=9
And the policy here is new for the efficiency guidelines
Effective 23-Jan-2019, the request limit for each account is calculated based on revenue performance attributed to calls to the Product Advertising API (PA API) during the last 30 days.
Each account used for Product Advertising API is allowed an initial usage limit of 8640 requests per day (TPD) subject to a maximum of 1 request per second (TPS). Your account will receive an additional 1 TPD for every 5 cents or 1 TPS (up to a maximum of 10) for every $4320 of shipped item revenue generated via the use of Product Advertising API for shipments in the last 30 days.
https://docs.aws.amazon.com/AWSECommerceService/latest/DG/TroubleshootingApplications.html#efficiency-guidelines
This has impacted me too and it's counterintuitive imo, you have to sell to use API but cannot use the API if you don't sell.
When I upload excel with updated products with variants comes error (exceeded 2 calls per second for api client) in shopify Api.
Like I have 1200 products and respective products have different variantd 1 ,2 3 etc.
when i will update that excel and then try to call api then some variant update but some are not update and give error
==>exceeded 2 calls per second for api client
so Please help me for this.
The error message is selft explanatory. It means you are exceeding the Shopify API call limit. More information on rate limitation is available on Shopify Website. It says
The API call limit operates using a leaky bucket algorithm as a
controller. The bucket empties at a leak rate of two calls per second,
which means that apps averaging two calls per second avoid bucket
errors.
To do so, you need to implement rate limiting in your application. As the PHP tag suggests you are using API via PHP, you can have a look at
Shopify PHP
It has a function checkApiCallLimit that ensures that your application does not exceed API rate limit.
$shopify = new PHPShopify\ShopifySDK($config);
Now any calls you make using shopify object, will respect the API rate limits. You can check the read me of linked library for more information.
Given a Stripe Payout (po_1BRxlK...), how can I determine which charges are contained in this payout? Right now the balance transactions in the API seems like a complete mess.
I've tried searching for all charges between two payouts, but due to the holding period of charges, there might be a shift of a few dates. How would you recommend to match payouts with charges?
I can see that within the Stripe Dashboard, you can see all transactions in a payout, so I assume it's possible to get the same data somehow via the API.
Thanks in advance.
You can use the List all balance history endpoint to do that:
https://stripe.com/docs/api/php#balance_history-payout
If you pass the payout id to the payout parameter you'll get back the list of all balance transactions aggregated in the payout. It only works with automatic payouts though.
You can achieve this by using Report API and API report type: balance_change_from_activity.itemized.1
For more info refer - https://stripe.com/docs/reports/financial-reports/api
Report Schemas - https://stripe.com/docs/reports/financial-reports/report-schemas
For quick reference - you can view the payout reconciliation from dashboard under Reports section.
I'm developing an e-commerce website using PHP and integrating paypal for processing the credit card payments.
I found APIs in PHP that are used to make payments and capture transaction id but none of these discussed about adding adjustments to the amount that is captured.
My use cases include:
Adding tip later
Adding time extension adjustments
Returning only portion of the amount if order gets cancelled
and few more of similar kind
May anyone tell me how this kind of a task is handled with paypal and also is there any API that will provide this functionality as well?
References Transactions would work fine to charge a separate transaction for the tip, but then the customers would see two separate charges on their credit card and you'll probably get lots of questions and confused people wondering why their card was hit twice. As obvious as it seems, I've been there.
The best way to handle it would be to run an Authorization when you first run the card. Authorize it for something like 50% above the ticket total, or whatever you think it would take to cover the final total including a tip for that order.
If the order is canceled for any reason you simply Void the authorization. If you're ready to actually process the funds with a final total including tip, then you can Capture the amount that you need up to the amount that you originally authorized. I believe you may even be able to capture up to 10% more than the original authorization, but I'm not 100% sure on that.
The thing you would need to be careful about is authorizing a card for some large amount and then not voiding or capturing shortly after. The authorization is only guaranteed for 3 days. You can run a re-authorization and get an additional 3 days if you need to.
If the order gets canceled and you don't void it then you'll get complaints that a large amount is "charged" on their account. It looks like a charge until it clears back or is voided. If you don't void it then it can take up to 29 days for them to get access to those funds on their account again, so you want to avoid those types of complaints too.
You would need Payments Pro to handle credit cards directly for that sort of a system. Depending on which version of Pro they put you on you'll use either the PayFlow API, or you'll use variations of DoDirectPayment, DoVoid, DoCapture, DoReauthorization.
Reference transactions would work for what you are trying to do. Reference transactions allows you to reference a previous transaction to run another transaction on that information at a later date. Here is a link to more information on reference transactions. https://developer.paypal.com/webapps/developer/docs/classic/express-checkout/integration-guide/ECReferenceTxns/
I couldn't find a definitive answer from the PayPal docs on this.
According to the docs:
The PNREF returned in the original transaction is valid in reference transactions for
12 months.
I want to avoid requiring my customers re-enter their credit card information every 12 months.
So what I want to do is to do a zero-dollar authorization to store an initial PNREF, and then update the PNREF value for that customer every time they do a reference transaction. So as long as the customer doesn't go for 12 straight months with no transactions, they won't have to re-enter their card information.
Having trouble finding an answer to whether or not that's possible via Google. Does anyone know if you can use the PNREF from a reference transaction as the ORIGID for another reference transaction?
Well I went ahead and tried it out, and I am able to use the PNREF of a reference transaction as the ORIGID in another reference transaction.
Now the million dollar question is, will this still work a year after the zero dollar authorization? Guess I'll let you know in about a year...
One year later...
It's been a year, and this has been working successfully for us. We originally save the customer's credit card info using a zero-dollar authorization (ZDA). Later, we do a reference transaction (call it T1) with the ZDA's PNREF as the new transaction's ORIGID.
Some time later, when the customer wants to do another transaction (call it T2), we use T1's PNREF as the new transaction's ORIGID. We then store T2's PNREF for use on the next transaction. So every time we do a transaction, we store the new PNREF for use on the next transaction.
This is how we've been chaining the transactions, and we have confirmed (ourselves and by a representative over the phone) that as long as 12 months doesn't go by without any transactions, we can keep chaining them indefinitely.
We have the same issue, or wish to do the same thing that Travesty3 had posted, we were pointed to this thread by PayFlow Pro Email Support.
However, before we got that response from their Email Support Team, we had ended up calling PayFlow Pro Phone Support and got the following explanation:
There may not be an easy way to perpetually or "chaining" keep renewing the PNREF. Especially when utilizing the Zero Dollar Authorization (ZDA). While the PNREFs returned by ZDA may work, they only last for a short period of time (+- 14 days). The tech support person who answered our call had consulted a senior tech to confirm this.
Now, apparently PNREFs returned by Delayed Capture or Sale transactions do last 12 months, but these aren't good solutions for us since we don't want to charge the customers' cards without actual purchases.
Yes, you can indeed use the PNREF of a reference transaction (ZDA or not) as the ORIGID for a new reference transaction.
One caveat however, if you're using PayPal Payments Pro (thus; PayPal is set as your processor) then I'll need to do some additional checking on this, as I'm not entirely sure whether it's supported in that scenario.
If you're using Payflow Pro with your own processor, then it's definitely supported.