I am familiar with the documentation on Stripe's website about the transfer_group property here: Transfer Options. However, I find this documentation rather limited and I'm still not sure what it does exactly.
One of the things that I'd expect to happen, is that the charge and associated transfer(s) are somehow grouped together on the Stripe Dashboard. But this appears to not be the case.
My question thus is, what does the transfer_group property do exactly and why would one use it?
EDIT:
I found some use for it now. It can be used in the following way:
const transfers = await stripe.transfers.list({
transfer_group: bookingId
})
This returns all the transfers associated with that transfer_group. Their id's can then be used to create transfer_reversals for example.
Note that the reason I'm not considering this finding as an answer, is because there must be more to it to this (I think).
It associates Charges with Transfers for use in Separate Charges and Transfers.
Related
Thus far, I've only seen examples/tutorials for stripe in which you declare an amount via choosen library to charge customers/clients. How would you write code that allows the user to input custom amount for say a "pay bill" or "donation" form. Conceptually it seems this might be an if/else statement that sets a high/low parameter but I'm not entirely sure nor how to code this to work with Stripe API. Could really use some help here. Ultimate goal is to make a simple payment page that allows user to make a custom payment and then create a customer object to charge customer at a later date.
(I realize this is an older question, but I figure the information might be useful to some people.)
Here's a simple example of a Checkout custom integration where the user can specify the amount.
Of course, Checkout doesn't actually create the charge, it only returns a card token. The amount value passed in the handler.open() call is only used for display purposes.
Once the form is submitted, in your server-side code, you'd need to retrieve the value of the amount form field and convert it to cents before making the charge creation request.
Additionally, you should validate the amount both on the client side and server side, to make sure it's an actual number, superior to the minimum charge amount and inferior to a reasonable maximum.
I am using the python-binance API wrapper.
After successfully sending a 'normal' MARKET order, I want to send in a STOP_LOSS_LIMIT order. If I'm not mistaken this is a subtype of Stop-Limit orders. This is what they are called in the Binance UI on the app.
Anyway, this is my code for the STOP_LOSS_LIMIT order:
order2 = client.create_order(
symbol='BTCUSDT',
side=SIDE_SELL,
type=ORDER_TYPE_STOP_LOSS_LIMIT,
TimeInForce=TIME_IN_FORCE_GTC,
stopPrice='33000',
price = '30000'
)
I get the following response:
Not all sent parameters were read; read '7' parameter(s) but was sent '8'.
Obviously there is something fundamentally wrong with the code. Can someone provide me with an example for this type of orders. What are the necessary parameters and what do they do. Please do not link me the official documentation. Sadly, there are no examples for these types.
Seems like what I was trying to achieve is not possible with Spot trading. Once I switched to Futures, it all worked out.
This is how I set the leverage to 1:
client.futures_change_leverage(symbol='BNBUSDT', leverage=1)
I conclude that Stop Loss/Take Profit orders do not work with Spot trading, either by design (which actually makes sense), or because of some bugs.
Anyway, if anyone ever hits the same wall, this is how to set a stop loss order on existing Futures (buy) orders in python-binance
FuturesStopLoss =client.futures_create_order(
symbol='BNBUSDT',
type='STOP_MARKET',
side='SELL',
stopPrice=220,
closePosition=True
)
Changing side to BUY sets a stop loss order on existing sell orders.
P.S. Achieving the same with Spot trading is most likely possible by using Websocket streams and executing Market orders when desired prices are reached. However I did not want to go with that route.
By API you can make it with this structure
StopLoss
API POST https://fapi.binance.com/fapi/v1/order
{
"side": "BUY",
"stopPrice": 40100,
"symbol": "BTCUSDT"
}
Hello Stackoverflow,
I'm writing API's for quite a bit of time right now and now it came to work with one of these bigger api's. Started wondering how to shape this API, as many times I've seen on a bigger platforms that one big entity (for example product page in shop) is loaded separately (We can see that item body loaded, but comments are still fetching etc.).
Usually what I've done was attaching comments as a relation in SQL query, so my frontend queried single API Endpoint like:
http://api.example.com/items/:id
And it returned all necessary data like seller info, photos etc.
Logically seller info and photos are small pieces of data (Item can only have 1 seller and no more than 10 photos for example), but number of comments might be way larger collection with relationship (comment author).
Does it make sense to separate one endpoint into 2 independent endpoints like:
http://api.example.com/items/:id
http://api.example.com/items/:id/comments
What are downsides of this approach? Is it common practice? Or maybe I misunderstood some concept?
One downside might be 2 request performed, but on the other hand, first endpoint should return data faster (as it's lighter than fetching n of comments), so page might be displayed faster and display spinner for comments section. This way I'll be able to paginate comments too.
Are there any improvements that might be included in this separation of endpoints? Or maybe I'm totally wrong and it should be done totally different way?
I think it is a good approach if:
The number of comments of one item can be large, because with this approach you could paginate it easier.
If you are going to need to access to the comments of one item without needing rest of item information
I think any of the previous conditions justify this decition, and yes, it is common approach.
Do I have to do this server side with a custom payment button instead of their (beautiful) default one? Or can I just do some logic with the javascript (price*amount) or will it not work with their custom token thingy they generate? I'm using their Java api with Google Appengine, if that makes a difference.
To add to the other posts, here's a concrete example of how I'm doing it.
On the 'pay now' page with the default button, pass in the amount. One way I'm doing this is from a form on a previous page.
Parse this amount, e.g.
<?php
...
$data_amount = $_POST['data_amount'];
...
?>
And then use this amount as a value in the JS script which actually process the charge
<script
src="https://checkout.stripe.com/checkout.js" class="stripe-button"
...
data-amount="<?php echo $data_amount; ?>"
...
</script>
Good luck!
The quantity and any other information about the items being purchased are irrelevant to the payment gateway, in this case, stripe. All that matters is the payment method (e.g. "visa card ending in 1234"), the amount, the currency and the customer.
You don't have to use the stripe provided checkout methods, you can write your own. The stripe examples are extensive and include Java code, though really the concepts are harder than the code itself (and the concepts aren't that hard). The token represents the payment method/customer and has nothing to do with the amount being charged.
You can do whatever you like to implement the product / quantity / price calculations. The Stripe API simply expects your server-side to make a "charge" passing the card (or customer) token, and supplying an amount and a currency. (There are a bunch of optional parameters too ...)
The "token thingy" does not contain an information about the payment itself.
I've not attempted to use Stripe myself. The above is based on a cursory (10 minute) reading of the documentation. But there are copious examples that you can find via the Stripe "Documentation" menu, including (Java) examples of what you need to do on the server side.
As the other folks have mentioned, the token doesn't contain quantity/charge amount info. The charge amount goes into the charge object.
Now, as far as additional info, particularly if you're coming from the classic PayPal world where you have quantities and so forth, or even if not but your purpose requires the back-end to know the extra detail, most (but not all) Stripe objects allow you to store key-value pairs in the optional 'metadata'.
If you're rolling up a cost (particularly if you're doing tax or other computations to get the total) you'll probably want to stuff the essentials (quantity, unit price, tax, itemized list, etc) into that block to be able to sanity-check and/or extract the details later on in the processing flow.
The Stripe docs are quite well done; click 'Java' at the top of the example column and you'll get cut-and-paste examples (for the most part).
What if I choose to use GMail's awesome mail archive search capabilities on my database? What if, for every transaction that my database is responsible, I emailed details of that transaction to a GMail address that exists for the sole purpose of searching and retrieving transactions.
Anyone logged into that account could search according to labels, invoice numbers, customer names - whatever using Google's search engine. The results are presented as 'email messages'.
Imagine a user working from the standard (web-based) GMail account searches for an invoice number via GMail's search box - he's returned all instances where the db did anything that included that unique number. Opening any of these 'email messages' would have the static text text included at the time of the transactions (historical and tracking gold) but could also carry a Gadget that could transform the 'message' into an editor so as to execute a new transaction on that invoice.
Imagine further that I wasn't the first one to think of this - cuz surely i'm not - and even if i were, i'm not smart enough to execute the idea alone.
Are you aware of efforts similar to this?
thx
[?belongs on superuser instead?]
An interesting idea, however given your search parameters it might be unreliable. Although gmail's search is great, I have found issues when searching for partial terms. Case in point, I had an email whose subject line was "stuffas". When I searched for "stuffa" I got no results, when I searched for "stuffas" I got the email in the search result. Additionally, I had an email with an 8 digit number inside the body. When I searched for 7 digits out of 8, I got no results, but when I put all 8 digits, the email appeared in the results. So, search in gmail may not be as powerful of a solution as you think. Again this is my experience, I'd love to hear if someone is able to partial search numbers in gmail.
I just had the same idea; 4 years after you. It still doesn't look like this has 'been done before' in any production sense. But now in 2014, I really don't see why not. Python packages for interfacing with gmail are already there and dead-simple to use. It does not take a whole lot of abstraction to turn this into a generalized key-value storage.
Its probably not exactly the fastest database, and not the best solution for everything; but as an easy-to-use, easy to search, trivial to configure, 100% uptime, cloud stored and backed up, free-as-in-beer database, its pretty epic as far as I can see.
Anyone else has seen examples of this having been done before?
Edit: having thought about it some more, there are several answers as to why this is a bad idea:
gmail does not permit random access from different locations; it will block you account. quite a showstopper
amazon simpleDB also gives you a simple key-value store with the same characteristics (plus good python support), and isn't THAT big of a pain to set up if you are willing to spend a day wrapping your head around it. And is also effectively free for the kind of traffic that youd be able to cram into a gmail account.