We have integrated the Stripe widget into our checkout, works great! UNTIL a customers card is declined then the total for some reason converts into thousands
E.g if a customers is paying for goods worth £520 and the card is declined the balance is converted to £52,000.
Stripe's amount parameters are in pence for British Pounds, and cents for US Dollars. You're likely doing some conversions wrong on your own end.
Also, you have provided 0 code, so this question kinda violates the SO rules. You should add more information and code snippets of what you've already tried or this question may be at risk of being closed.
Related
We have a web-app (react based).
There are two sides to the app.
Can be thought of as an app where companies give tasks to individual talents, approve the payments and at the end of the month, the company gets a single monthly invoice and we take care of paying the talent in their preferred currency/payment method.
Apart from this service we provide these companies a lot of additional features (and hence charge a 3-5% markup on this transaction).
I'd want to discuss what will be the most optimum method since the margin is already really thin for us.
Example: Company has 5 talents and each talent is supposed to get $20 for this month corresponding to the task that they completed
Hence the total bill (invoice) that the company will get from us is $100 + markup fees of let's say 3% = $103
Our commission is $3 and remaining $100 will be split amongst the talents, who will get $20 each.
What we thought of presently is to use Stripe Connect for individual payouts and use the split payment functionality.
But the problem is to receive payments Stripe charges us an additional 2.9% + 30 cents, which will make this thing non-profitable for us.
Hence wanted to get some expertise because there are already softwares that have solved this and I was wondering how ?
I wonder to find a solution for payment using Stripe. My clients create an event and we split the bill all members who joins the event. Let's say a football game $100 / 10 players, we hold a place until cancellation term is expired, or the game is canceled. What I am looking for solution and if it is possible to make, for the same event, instead of 10 players, 15 joined or 5 only, which means the bill from each varies from $6.60 to $20. I want these players to see that range of the pricing from $6.60 to $20 and book their spot and agree that when event occurs, they will be charged anything between. I remember that was the same solution with Uber at the beginning. Can anyone share any ideas if it is still possible to create this way, maybe they are new legislation and we need to show the total amount. Thank you for any suggestions.
You can use Stripe to save payment info and then charge your customers later:
The Setup Intents API lets you save a customer’s card without an initial payment. This is helpful if you want to onboard customers now, set them up for payments, and charge them in the future—when they’re offline.
You may also be interested in placing a hold on a card and capturing funds later, assuming the time limits work for your use case.
Based on what data does a POS terminal decide if it needs to generate a ISO 8583 100 (Authorization Request) message or a ISO 8583 200 (Acquirer Financial Request) message.
Also how does POS decide if it needs to prompt the user to enter his card PIN or not.
Any reference to documents on ISO 8583 message generation at the POS will be very useful.
Thanks
A 200 message is what ISO 8583 calls a Financial Message. It is used to transfer funds into or out of a cardholder's account.
A 100 message is what ISO 8583 calls an Authorization Message. It is used to check that the card holder's account has enough funds to cover the amount of the transaction and to reserve that amount (and sometimes a little more) for a certain period of time. It does not actually take any funds from the account. At a later time, a 200 (actually a 220) message can be sent to take the money from the account).
100 message are usually used in situations where the transaction amount is not known at the time or where the delivery of the good or service is not immediate.
So for example, when you check into a hotel, the hotel wants to know that your account has enough funds to cover your expected stay (and maybe a little extra in case you order room service or use some other service), so a 100 message might be sent when you check in, and then at checkout time, a 220 message is sent to actually transfer the funds from your account.
See the "Message Class", "Message Function" and the "Examples" sections of this Wikipedia entry on ISO 8583.
As far as, "how does the Point of Sale (POS) device decide if it needs to prompt the user to enter his card PIN or not", there is no one answer that works in all situations, for all merchants, and in all countries.
For example, in some cases, PIN entry is required for all debit cards but not allowed for any credit cards. In these cases, the POS device needs to know whether the card being used is a debit card or a credit card. It can either ask the operator or it can attempt to use the card number and/or mag stripe to determine this. A table of account numbers or Account BIN numbers (the first few digits or the account number) can be stored in the POS and used to identify the type of card (sometimes). see Bank Card Number).
Sometimes just knowing whether a card is credit or debit is not enough, there are cards that can be used as either, there are debit card that can used without a PIN, and there are credit cards that allow/require PIN entry.
Both credit card terminal and credit card have a list of preferred customer verification methods, the most common ones being 'signature', 'PIN', and 'identification'.
The terminal then takes the verification method that is ranked highest by the card and supported by the terminal.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I operate a Dry Cleaning & Laundry delivery business. When client's place an order for Laundry, the customers are charged on a per pound basis AFTER their laundry has been cleaned. As a result, this creates a payment processing issue for me as the payment processors I have been in touch with tell me that I need to pre-authorize a set amount for each client when they place an order and then invoice them if they go over that amount after the cleaning has been done. From your experience, is there a way to do the following:
Have a customer fill out a registration/sign up form on your website (e.g. collect customer name, address, credit card information). Please note that I do not need to see the credit card information, I just need to be able to charge it later on.
Facilitate a customer order (e.g. pick-up my laundry tomorrow at 6pm from my house).
Charge the customer the full amount they owe you AFTER you drop off their clean laundry
A similar company, Washio, is using the exact same process I described above, but I don't know how they're doing it.
Can anyone please provide an answer to my dilemma?
You do a AUTH_ONLY (Authorization Only) for the maximum amount you think the payment will be. This will freeze that amount on the customer's credit card (note, this means those funds are not available to the customer until you capture them or release them so do not do an arbitrary large amount).
When it is time to make a payment you would do a CAPTURE the sale by sending an a mount less than or equal to the amount secured using the AUTH_ONLY. If the amount is less than the amount initialing frozen the remaining funds would be released.
Stripe has a great in-built system for capturing data as a "customer" and a "card", which can then be processed at any time after the fact.
There's no guarantee your customer will have available credit on their card, but you can capture & verify their information without charging any amount.
This happens on Stripe's servers (and not stored on your own) so you're PCI-compliant out of the box, as long as your transaction occurs behind an SSL secured connection.
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