I understand Parallel payments are limited to 6 receivers but what about Chained, it only says multiple receivers.
We plan on having many items in our catalog and know that many will purchase more than 6 items, each items will be split by 4 , 1 will be developer but what if you had 12 items that 3+(1*12) which would be 15 receivers. Is there a way to do this?
Also can you have each account pay their own amount on the fees or does the primary get stuck with the whole thing?
Thanks,
Jeff
The Pay call in general is limited to 6 receivers. PayPal may be able to open that up for you but you'd have to discuss that with them during the process of applying and getting your live App ID for your app.
When working with the Pay API you can use the feesPayer element to specify how to handle the fees.
If Adaptive Payments -> Pay simply won't work out for you, you could go ahead and setup a regular checkout system where the buyer sends you all the money, and then you could automate the process of sending money from that out to the people who need it from the order using an IPN solution.
You'd still be limited to 6 receivers in a Pay request, but you could make multiple Pay requests within your IPN script. Alternatively, you could use the MassPay API to send money to up to 250 people at a time.
With MassPay, though, the sender pays the fee, but the max fee no matter how much the amount is would be $1.00. You could simply work that (and the original payment fee) into your deal with your partners so that the fees get split up accordingly.
Related
I am trying to display a users transaction history in binance, including fund deposits and withdrawals as well as buying and selling of different crypto's. Does anyone know which binance API endpoints I would use to do this? It seems quite complicated in comparison to other trading platforms.
Thanks
This is the link to the docs: https://binance-docs.github.io/apidocs/spot/en/#withdraw-history-supporting-network-user_data
I can see the Wallet endpoints "Withdraw" and "Deposit", but this won't cover crypto trading will it?, The account trade list call would be ideal, but it requires a symbol input which I'm not sure how I would obtain dynamically.
I would also like this endpoint to provide me with the data so I can get the avg buy price for a crypto
Currently this is not supported. See: https://dev.binance.vision/t/fetch-all-account-orders/279/3
This is the route you're looking for to get the user trade history. The big downside is that you have to specify the exchange symbol, you cannot get the history of the account with just one request:
https://binance-docs.github.io/apidocs/spot/en/#account-trade-list-user_data
Get your account information first. You can then extract non-zero balances from here to get symbols for transactions. You can then loop through each currency pair and get its transaction history. This seems to be the most optimistic way we can get right now
You can also try to use caching. For example, you can remember balance for a particular coin, and if it has not changed by the next launch, then it is likely (but not 100%) that no transactions were made with it
You can also connect to WebSocket, but this is still a terrible crutch and requires a DOS attack to get the necessary data
Please note that here the balances for Savings wallet have LD prefix added to their ticker. For example, BTC in the Savings wallet is labeled as LDBTC
Reconciling deposits, within an accounting system, coming into a Shopify User's bank account from a Shopify store running Shopify Payments (or otherwise) appears to be one of the things people frequently stumble on — based on the number of requests about the topic on Shopify's Support Community Forums, for example: https://community.shopify.com/c/Shopify-APIs-SDKs/Fees-charged-by-Shopify-via-API/m-p/265261/
The issue (for accounting) is that Shopify Payments removes the Fee Amount (for a full list of fees see: https://www.shopify.com/pricing) prior to depositing the balance of the transaction into a Store Owner's bank account.
Shopify Fees generally look something like: 2.6% of transaction value + $0.30
Calculation of the fees that should be taken out based on the above is pretty simple (hard code the fee schedule), until those fees change at some point in the future.
How does this impact Integrations?
For many of the available simple integrations this causes a discrepancy between the invoice amount of money hitting the bank account and the amount of money we 'Expect' to hit the bank account based on the Shopify Invoice Amount that is readily retrieved via Shopify's API by many such solutions.
That discrepancy means that it is necessary for an Accounting based user to manually deduce which Shopify Invoice is associated with which incomming bank deposit — and then manually add a negative line item to account for the difference / balance the books.
This is the suggested methodology coming from several different Accounting System / Software vendors (specifically Xero and Quickbooks) when asked how their customers solved the above issue.
I know that there are solutions out there that attempt to solve all of the above problems (with varying degrees of success), but due to the amount of Kitting that my current situation involves none of them adequately solve the other required functionality for our business.
We need to be able to find the fees (or alternately calculate them ourselves) and add those fees to the invoice so our accounting system is expecting the correct amount of funds to hit our bank account — hence the question: How can we retrieve the current accounts "Shopify Payments" fees / rates.
Ideally I want to avoid hard coding this information since Shopify likely does change the fees (potentially with only minor notification) meaning that at that point our integration would break. It would be much better to be able to retrieve the fee schedule for a given account via API request thereby avoiding issue if the fees change.
I have multiple clients who are also facing the same issue — so I figured it was worth checking to see if anyone has faced / solved the problem, and discuss my current solution
What does Shopify Say?
Generally their comment is that there is no road map to including the fees deducted from an invoice when responding to an API Request as taken from: https://community.shopify.com/c/Shopify-APIs-SDKs/Fees-charged-by-Shopify-via-API/m-p/265261/ (which seems strange) — meaning that 'wont do' is the best classification for the feature request that would provide this information with simple / readily available calls to the currently available API Endpoints.
Without access to Fee amounts on a per order basis I am not sure how Shopify Stores are currently interfacing with their account systems.
I would love to hear solutions from any Shopify user who may have encountered this issue previously! I opened a ticket request with support so I will see what I get back over there as well and post back.
OK so this isn't a total solution but I am updating as I go and will continue to edit this answer until I find a full solution (or until someone who has one adds an answer).
Whitelist / API Endpoint Approval Required
I found a Shopify API endpoint that should give the information I am looking for over here: https://help.shopify.com/en/api/reference/shopify_payments/transaction
According to the Shopify API docs the response should contain the Fee Amount and the API Endpoint would be:
/admin/shopify_payments/balance/transactions.json
That would get me exactly what I need, except that sending a properly formatted request to the avoid Endpoint gives the following response:
{
"errors": "[API] This action requires merchant approval for read_shopify_payments_payouts scope."
}
Basically it seems like it needs to be approved per merchant making it a less than ideal solution for you guys as an App. I requested the functionality and will add to this if it makes something easier (when / if it's granted to our account).
Public Access to Similar Fee Data
While playing around with some of the other endpoints I ran into this one (which IS public and accessible for Apps — I am a partner / develop Shopify Apps myself) which seems to provide similar functionality:
https://help.shopify.com/en/api/reference/orders/transaction
When making a call (and receiving the "kind": "sale" result for a given Order Id) I get the following pieces of JSON that are interesting:
"gateway": "shopify_payments",
"status": "success",
and more importantly:
"balance_transaction": {
"id": "XXXXXXXXXX",
"object": "balance_transaction",
"amount": 12881,
"available_on": 1553040000,
"created": 1552943224,
"currency": "usd",
"description": "XXXXX#outlook.com",
"exchange_rate": null,
"fee": 339,
"fee_details": [
{
"amount": 339,
"application": "ca_1vQrdCwnvOuC2Ypn5R9whwXkGxb4XJjx",
"currency": "usd",
"description": "Shopify Payments application fee",
"type": "application_fee"
}
],
Where the JSON 'amount; property corresponds to the invoice sales amount (including shipping) as a decimal free value.
The "fee": 339 appears to indicate the fee amount deducted by Shopify Payments (based on the JSON idicator attached: description": "Shopify Payments application fee").
Yep. That's the Fee.
After checking the Shopify Account tier (in this case Advanced) the fees deducted should be: 2.4% + 30¢ meaning that the total does match — 2.4% * $128.81 = $3.09144 + 30 cents (per transaction) = $3.39.
So basically everything exists (with no whitelisting required) to get the fee amounts on a per order basis for Shopify Payments users. This probably includes the Shopify Fees charged to external gateways as well although I don't use one so I can't say for sure.
That endpoint functionality means Shopify Fees likely COULD be added to any Shopify App that integrates with an accounting system — but also means it is relatively easy to pull in after the fact if the integration you are working with deposits the Invoiced amount into accounting but DOES NOT add a negative line item associated with the Shopify Fees — like mine does.
Still leaves me with some questions but at least the initial 'How do I find the Shopify Fees?' question is taken care of.
Previously my scripts that handle our accounting had used the Shopify API. As one commenter mentioned this API no longer works (or has changed in some way I have not found a solution to)
For everyone who is now having trouble with the API changes and doesn't mind a slightly manual solution to grab all Shopify payouts information you can dump a CSV out of the Shopify Payouts view, and then load that into your script (or alternately into Google Drive, and then hit that as a database... for example with Autocode's Standard Library).
To export Shopify Payouts data in CSV:
Go to the Shopify Payouts page for your Shopify store: https://XXX-YOURURL-XXX.myshopify.com/admin/payments/payouts
Set your date range / filter range to make sure you are exporting the correct payout date range.
Click the Export button in the top right hand corner, to the left of Documents and Transactions.
Shopify will email you the exported Transaction CSV which you can then do with what you like. This process won't work so well for anyone who is attempting to use a daily payout reconciliation strategy within their accounting system, but for the rest of us peons who are further behind on reconciliation it works well.
I am making changes to my companies internal paysite in order to come into compliance with the new credit card regulations. We have decided that when we get a split tender transaction that comes through we want to get the remaining balance along with how much was on the card to start out with and send that info back to the customer service rep with a message relaying the need for another payment source along with the remaining balance and the amount that was originally on the card.
Instead of chaining the transactions together with the split tender Id we have decided we would like to finalize each split tender transaction with a prior_auth_capture and then request the next payment source and amount and process that transaction in the same manner. I know that we are side stepping the functionality some but those are my orders.
My questions are, is this feasible and possible and how do you do this in code? I am using the C# SDK to implement this in VB.NET 2008
My thoughts are that I would have to process the transaction for the amount passed as a auth_capture transaction and then some how do the prior_auth_transaction with a zero amount or something?
How would this work?
Thanks for much for your help.
James
This is not feasible to do. The purpose of split tender payments is to logically group together split payments into one transaction. By breaking it up into multiple transactions it can get confusing for you, the users, and the processor. Especially if you have issues getting the user to make full payment on their transaction. Failing to void the other transactions would be very problematic. This almost certainly will result in an increased exposure to chargebacks.
I've been researching eCommerce payment gateways and service offerings, but I'm an eCommerce novice, so please excuse my ignorance.
I wish to set up an eCommerce solution with the following requirements:
User "subscribes" to the service on a yearly basis. This service includes a single product subscription for a set amount (let's say $50/yr).
User can "subscribe" to additional product services for a lesser rate per year (let's say $25/yr).
I will need to store a product service unique Id of some sort for each product subscription the user subscribes to in order to show them product unique information. I also need to prevent duplicates...for example, user can subscribe to product ABC and XYZ, but not 2 of ABC.
Is PayPal the best solution for something like this? Is there a better solution? Any assistance is greatly appreciated, even if just links to specific tutorials or examples.
Update: It looks like Chargify could be the perfect solution.
You can also use Authorize.Net's CIM solution which, based on what I read at the chargify website, does most of what chargify does except your customers never need to leave your website. The Customer Information Manager allows you to create profiles for your members. These profiles store sensitive information like credit card numbers and billing information so you don't have to worry about PCI compliance or hackers stealing your information. You then can schedule a cron job to charge them monthly for whatever amount they owe based on their current subscription. Since you control when the payments happen it also allows you to charge them pro-rated amounts for subscription changes mid-month.
[link text][1] seems to be the best solution for me. I still need a merchant account, but this takes a lot of the headache out of handling the subscriptions.
[1]: http://chargify.com Chargify
on my website I sell unique items. I have programmed it so that on the selling page, users can select any amount of these items, and it calculates the cost. The key is that I only have 1 of each of these items. So I need the shopping cart system to not allow the payment to go through unless it is available.
I've been searching for a good quick/easy/cheap solution and can't find one. I don't expect this site to make a lot of money (the transactions are a few bucks), so I didn't want to need a ssl certificate.
The only way I know of not needing an ssl certificate would be to use paypal or google checkout. However, I do not think there is a way of using these services and making paypal's server run a script to check how many are available on the site. Any solution?
Thanks
I was thinking about it more, and I think the problem is that once the user gets to the paypal payment screen, I have no control. I guess I could do something like they click the buy it now link, a php script updates it to sold, then they go to the paypal screen, but then they might not continue the purchase...
If you use PayPal Website Payments Standard (using a cart rather than 'Buy Now' Buttons) then you could use IPN or PDT (see the paypal docs here) to get PayPal to call back to you with the status of the payment.
The work flow would then be to set status to reserved when the item is added to the cart, and then wait for the IPN/PDT call to come back with the payment status, and mark the item as sold.
You would still need to check and reset to available any item that had been reserved for longer than say 2 Hours. (You could do this before serving a page to a user so that they have the latest availability and you don't need a cron job or long running process)
If you could provide a little more information about how you have implemented ur shopping card, it would have been more easier for other to assist! If you are using any ecommerce solution then it should be there already in the track inventory section. But Provided that you have implemented d shopping cart manually, why don't you add little bit of codes that checks the inventory status first before letting your customers check out?