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.
Related
In the chat application i am developing with dialog flow has scenario like this. Users can ask details about loans that they can get. that is a one intent. once user says the loan type they want i need to save it and use it every where when they ask question. for one example i have a another intent called loan payments.
In that intent they can ask questions like
I am interested in getting a personal loan for a duration of 5 years
and the loan amount would be 5 million rupees. Can you let me know the
monthly repayment amount?
to calculate that, loan type is a must (personal loan in this case). so if any user has specified the loan type before i need to use it here other wise i need to ask users to provide it again. but if i am using context i cant add add required. how to achieve this. also since i have already set the parameters i cant change the value of them. this is how my parameters look like
This is where your business logic comes in picture. Chat application can be built in two ways, directional & open-ended. In first one, you can explicitly go on asking few questions with set options/buttons for the services that you're offering & user has to select any one of them or in the second one, you keep it open for people to type-in anything & then you extract values & respond them based on their inputs.
Now that you're of second type, even if you use contexts, dialogflow offers you a favor to extract parameter values of first intent in the second one. You just have to use, #context_name.parameter_name. But now, if you're saying that if user has already defined loan type in earlier intent then you don't want to ask him again it in next intent, then this is purely a business logic that you will have to code in your webhook. Dialogflow won't do it for you.
I hope, this answers your question & if you don't want to do it that way, go for directional flow.
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.
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).
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.
I have a backend that generates gift codes, each with a certain number of uses. Give these to a blogger or whatever, and their readership can redeem the code for a promotional item.
I'm working on the best way to check a codes validity without having collisions/dupes, or anything like that. I need to 1) validate the code 2) collect shipping info
My first draft was
A) Check code via a form, if good, proceed to address input. When input is received, save code and address/name etc.
This fails because if there are 74 uses on a 75 use code, 25 people could "validate" but not enter their address yet, and we'd end up with more than 75 valid redemptions.
My current solution looks more like:
B) Just have the code as the first field in the information gathering form, and when a valid code is typed in, ajaxify that and live check it against the DB. If the code is valid, it then shows the rest of the form, and that entry of the code is "claimed" for half an hour or something. If no DB entry w/in half an hour, it's then released.
This seems pretty complex, and I'm wondering if I'd need to do throttling against the ajax attempts to make sure people don't brute force a valid code.
Is this method secure, and/or are there any other blatantly obvious patterns I'm missing for this type of application?
Let everyone enter their gift-code and address, and then submit
In the backend, verify the address and the gift-code.
If the gift-code is valid and not exhausted, congratulate the user. Else apologise to them and suggest they buy it instead anyway.
Does it have to be more complicated than that?
Why don't you just have one form with all the information (redemption code and shipping info)?
Then, when the user submits, atomically (using transactions on your database) check if it's valid and commit the user's information.
If the code is no longer valid, just show a message like "Sorry, the redemption code you used has been depleted and is no longer valid."
Just wanted to add, if you're worried about bruteforcing attempts, you can require a captcha or javascript based hashcash value to be submitted along with the gift code. If you want to be as unobtrusive as possible, you can only require this for subsequent attempts after the first failed one.
One thing you might consider, is after the user enters a gift code, create an intermediate page that has more details about the offer, shows the number of claims remaining, and has some information about what will be required to complete the offer (address, creditcard, whatever). If the user chooses to claim the offer, have a 10-15 minute countdown (updated via javascript) on the data entry page for the address and other personal information, so the user knows that the offer might expire if they don't enter their information immediately.
Another thing to consider is implementing a "cancel" button that indicates the user can make the offer available for another user, without waiting for the countdown to expire.
Your current solution looks like the proper one, although I think you left out the method by which you associate the user association with the code. Still, providing the functionality of "reserving" a redemption of the code for a user is a good solution.
Option B seems reasonable. Just use a captcha rather than trying to throttle it. Captchas aren't perfect but it's less obnoxious than say misreading the code three times and then being denied the ability to try another for 24 hours. This will work particularly well if you're already planning on doing it AJAXy.
So -
User will fill in code field and captcha.
You'll confirm the captcha, then confrim the code.
Once successful, the user will fill in the other info and submit.
Using this method you could also probably only lock the code for something more like 5 minutes (ticket agency style) and show a timer on the form somewhere notifying the user.
Your A method (Check code via a form, if good, proceed to address input) looks very reasonable. Just combine it with B's "code is "claimed" for half an hour or something", and everything should work as you expect.
That is:
Customer enters code
Check code – if valid, and not already used MAX+ times, add an extra entry in code use table, with a timestamp that expires after x minutes.
Collect other info
On submit, permanently mark the code as used (remove entry expiration)
If customer never makes the order, the timestamped entry is removed (or ignored) after time x, and released for others to use.
We do a low end encryption (RC4) with a checksum added for this type of thing. Because RC4 generates a problematic character set, we also converted it to HEX. The combination is relatively secure and self checking. The decrypted value is just a number that we can verify in the database. This works with both our eMail reminders and gift certificates.