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).
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"
}
The Image below is a simple use case of a cashier System.
The flow is as follows for the general flow of a check-out
Cashier scans item(s)
Cashier select a payment method
2.A.1 Cashier select payment via credit card
2.A.1 Cashier swipe the credit card onto the reader
2.A.3 Payment is done
2.B.1 Cashier select payment via cash
2.B.2 Cashier input amount received.
2.B.3 System display the change to be given to customer.
2.B.4 Payment is done
Check-out completed.
The question i wish to know if it is valid for the extend to be used in this scenario, where either one of them will occur when a payment is made.
Based on my understanding is that extend means the base case has the option to call the extension. Does my use case model means that there is a possibility that both method are not called (which should not be the case)?
No. This is not correct. Payment via ... is not a use case. It's a constraint for Make Payment (either/or). You are trying to use include/extend for functional decomposition. And this is not right either. Avoid them. If you need to "order" use cases then use pre-conditions to control this.
See also here.
I'm trying to set up a google wallet payment process for users to purchase an entry into a tournament. In order to do this, the user has to fill out a bunch of information about themselves (name, league player number, contact phone number, etc), and there are some other pieces of data that are implicit, such as a unique identifier for the tournament they're entering.
It seems like there are two ways to accomplish this in Google Wallet, and I'm wondering if I'm missing another, better workflow and/or if one of these two ways is preferred.
Possibility #1
When the user clicks the wallet button, I serialize the form and submit it to my server using ajax. If the form is properly filled out, the server encodes everything about the form into the sellerData field of the JWT, and returns the JWT asynchronously. I then pass this JWT to wallet, expecting to receive it in my postback handler.
The postback handler then constructs the entry using the information from the JWT sellerData field and records it in the database.
This possibility is intuitive to me, and I've implemented it, but I'm running up against the 200 character limit for the sellerData field, since it contains multiple peoples' names, phone numbers, and various other form elements. There's just no room. I don't have a workaround for this, and would welcome thoughts.
This approach has the advantage that nothing is created in my database until payment is successful, but I don't know how to work around the difficulties with representing the entire form in the JWT to get it to the postback handler somehow.
Possibility #2
The user just submits the entry form using the normal web-form submission process, which creates something in the database. Database objects newly created in this way are marked as "unpaid", and are therefore incomplete.
Once the user successfully creates their entry in the database, they are then presented with a second page at which they can pay. This works better because I can now just put the database key for the object they just created into the sellerData field, and not worry about the size limit.
It does have the unfortunate side-effect of having these half-completed objects in the database, as well as running the risk of users not quite understanding the two-step register-and-then-pay process, and forgetting to pay. I'd have to be quite careful and proactive about making sure that users realize that A) it's okay to submit the form with no payment information, and B) that submitting the first form doesn't mean that they're done.
Thoughts?
I think Option 2 is a pretty standard buy flow. Step 1 enter in your information Step 2 confirm your information and pay with Wallet.
The onsuccess callback could then redirect the user to a purchase receipt page.
My consumer mind doesn't see any purchase flow red flags.
I ended up going with option 2, because it was simplest for me and I didn't think it would confuse users.
I missed a third option, though, which is that I could allow people to buy a blank entry form and then fill it out after purchase. I think this might have even been better; it matches the in-person buying experience better and would therefore be more familiar to purchasers, and it avoids the problem of people who think they've registered but somehow didn't realize that they had to pay.
This is probably more question for technical support of Payflow Pro, but anyway. We are trying to implement repeated charging of one credit card by Payflow Pro payment with ActiveMerchant. We need the customer to give the credit card info once and then be charged every month for variable amounts. However, there does not seem to be any explicit STORE method in the Payflow API even though it has to be somehow possible as the RECURRING billing is part of the standard. Are we missing something and there are methods for that or we have to use some workaround?
Ok, figured it out myself in the end, just FYI: this has nothing to do with the recurring payments. You can simply "STORE" credit card by issuing and voiding some small amount transaction and then later, instead of puting credit card details, you put the returned request.token (or 'pn_ref' in payflow terms).
Something like this should work
module ActiveMerchant #:nodoc:
module Billing #:nodoc:
class PayflowGateway
def store(credit_card, options = {})
stored = purchase( 1, credit_card)
return stored unless stored.success?
# we may charge some money we should not but I guess there is
# no better way for now
voided = void(stored.authorization)
return voided unless voided.success?
return stored
end
end
end
end
Yes, that's the way I solved this problem too. PNRefs are quite handy for implementing your own recurring billing system... However, you'll be charged for $1 authorization-and-void amounts as well, I think, because VISA and others started to crack down on the use of those as account verifications. They're now recommending that you use ZDA (zero-dollar amount) authorizations, which return error code 0 and the response message 'Verified' instead of 'Authorized'. This works with all merchant banks -- unless PayPal is your merchant bank, in which case you'll get an error code 4 - 'Invalid Amount'. If PayPal is your merchant bank, they just recommend doing the $1 authorization-and-void, and apparently they shoulder the VISA fees.
Here's a good article on the fees and recommended practices for doing zero-dollar authorizations:
https://www.x.com/docs/DOC-1561