I'm using Rails-Stripe-Membership-SaaS which makes use of Payola. Payola assumes you want to create an immediately charging subscription. This means free plans and plans with free trials require a credit card at sign up. I'd like to get around this. I've made a fork here: https://github.com/archonic/payola
Where I'm confused is the specifics of how to complete the first step here:
Stripe - How to handle subscription with a free plan and no credit card required at sign up time
Stripe doesn't require a card for free plans or plans with a trial, but I'm not sure how to create a token without a card. How can I get a token with just an email before I call create_customer?
You don't need a token to create a customer. Just go ahead and call the create customer API like this:
customer = Stripe::Customer.create(
email: "test#example.com",
description: "...something..."
)
# do something with customer, save id in db/etc
You can subscribe that customer to a plan that has a free trial without it needing a card attached. You could even pass plan: 'someplan' in that create customer call if you wanted so long as the plan has a free trial.
Related
So I have everything implemented with braintree and rails. However, I wanted to switch it up a little. I have a user role which is a business account. When someone wants to sign up as a business account I want them to pay before the devise registration is actually saved? I've seen it on a lot of website but cant really find any resources online how to do it. Someone please give an example of how it can work.
As a general Idea what you can do is one registration of user on business account take the card information also for billing.
On submit of that information it will go to a controller action with all the params of registration and billing.
Try to charge the card through brain tree and if they payment is successfull you can register the user because you have access to the params and you can save this transaction for the user also.
Its just a general idea that how can you implement it.
As one of the comments say, you question is vague.
What I would do is to have a column in that table that tells whether the record has payed or not.
If it hasn't payed then restrict its ability to log in. This way you can still record its information and it may be usefull for some cases, say to remind that user through an email that he/she should complete its payment.
Our user flow is like this:
User will request service with apple pay
(PKPaymentSummaryItemTypePending)
Stripe will provide apple pay token
We will provide the service
We will charge the user for the service
We have a radar rule to block prepaid cards. Unfortunately, if you use apple pay with a prepaid card, it will pass through steps 1 - 3, then get blocked at step 4.
Therefore user will get the service free.
The goal is to block them at step 2.
How do we validate the card before step 3?
Upon creation of apple pay token, check at the "funding" of the card and block it if it is prepaid
Instead of just charging the apple pay token, attach it to a customer object then simply charge the customer later.
From Stripe:
reference 1
When you have a Radar rule set on your Stripe account, it doesn't
actually run the rules on the tokenization stage. Instead, it runs
when the charge attempt is being made, which is why it didn't occur
when you first tokenized that Apple Pay card. When you tokenize a card
and attach it to a customer object, we do a $0 or $1 authorization to
ensure the card details are valid. This doesn't run anything like
Radar rules on the card, however. It's only a step to make sure we can
theoretically charge a card.
If you're looking to be able to "block" prepaid cards in the
tokenization stage before a charge is attempted, this would need some
custom development, as the Radar rule you have in place to block
prepaid cards will only work in the charge stage. To prevent prepaid
cards from making it past the token stage, what you can do is have
some code in place on your end that looks at the "funding" of the card
token after you create the token. This tells you what type of card it
is, such as a debit, credit, or prepaid card.
https://stripe.com/docs/api#token_object-card-funding
If your code confirms it's a prepaid card, you can simply stop the
charge process here and instead choose to show your customer that
prepaid cards aren't accepted, and to use a normal debit or credit
card
reference 2
Stripe will automatically attempt a $0 / $1 authorization once you
attach a token to a customer. The authorization will happen once a
customer's created, or if they're using Checkout. Here's a link with a
little more information:
https://support.stripe.com/questions/why-does-my-customer-see-an-extra-1-00-charge-on-their-statement
That authorization doesn't use the token, it's a back end event that
happens on our side.
I'm making a task website similar to Taskrabbit where users can post tasks they want completed and others can make an offer for how much they'd charge to complete the task.
I'd like to use Braintree Marketplace with Devise to create individual "merchant accounts" associated with each user, but I'm having trouble figuring out how to make each user a merchant once the user has signed up.
Braintree has a "merchant create" action:
result = Braintree::MerchantAccount.create(merchant_account_params)
but I'm not sure what to do with it.
I have a Transactions controller for Braintree transactions, but that doesn't seem like the place to set up merchants. Would I need another controller? Or can I make a method in my User model to verify their account so they can receive money?
Any help would be greatly appreciated!
Thanks,
Zach
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact our support team.
As outlined in our Marketplace guide there are 3 steps to set up a sub merchant and have them start transacting. They are:
Creating the Sub-merchant
Confirming the Sub-merchant
Transacting with the Sub-merchant
Once the sub-merchant has been created/signed up, then the submerchant must be confirmed on Braintree's end. This process happens asynchronously and we notify you of the status via a webhook. To receive this webhook you need to set up an endpoint that we call into.
After the submerchant has been confirmed, then you can start transacting with the merchant by indicating the submerchant to associate with the transaction when the transaction is performed.
Using the PayPal REST API, I cannot seem to figure out how to cancel a payment after a client clicks the "Cancel order and return to website" link. Perhaps in production mode PayPal cancels these payments automatically, but in sandbox mode they seem to stay in the "created" state.
That observation lead me to believe that I need to programmatically cancel each payment upon return to the website's "cancel_url" page. However, I cannot seem to find a cancel function in the PayPal REST API documentation.
https://developer.paypal.com/docs/api/
For what it's worth, I'm using the Ruby API.
I have been in contact with PayPal's technical support last week and this is what they said:
If the buyer has completed the work on the PayPal checkout page
without cancelling the checkout, then they are redirected back to your
site. If you wish for them to have a cancellation at that point, you
can build the Return URL to have a final confirmation (showing final
total to be billed). So at this point the buyer is on your site, but
the payment execution has not happened. If the buyer decides to
proceed, then you run the execute command, updating your database with
the successful payment details. If the buyer decides to cancel at
that point, you do not run the execute command, and purge the payment
ID and the buyer's Payer ID. There would be no request that you would
need to pass to PayPal to cancel what the buyer did on PayPal. This
would be the same type of process done with the Classic APIs using
Express Checkout. Once the buyer gets sent over to PayPal, they
choose the funding source and shipping address and get sent back to
your site, if they want to cancel the transaction, your site does not
send any API call to PayPal to cancel or void the EC token. It is
just not used to collect the payment.
When asked how to handle non-executed payments and if they automatically void non-executed payments after a certain amount of time:
Yes, I recommend deleting the Payment ID from your database, so there
is no accidental payment. Our system, by default, will expire the
payment approval made by PayPal payers if the payment hasn't been
executed within 3 hours.
Permission has been given by PayPal to post their answer here.
I actually talked directly with someone from PayPal. The answer was:
Once a user authorized a sale, the sale has to be executed. It cannot be canceled
past beyond that point. So if the user comes back on your return URL, you are
simply expected to run an "execute" command on your payment.
This may not directly apply to your case. I think that the only way to "cancel" would be to first "execute", then apply a full "refund". Otherwise, never execute (which I also view as strange because that looks like a potential for security problems. That said, the main problem that could happen is an "execute" on the payment and your company would receive the money that you can then manually refund if necessary...)
I think you need to void the authorization of the payment:
https://developer.paypal.com/docs/api/#void-an-authorization
I used paypal api v2, and there is cancel order api.
https://developer.paypal.com/docs/api/orders/v1/?mark=cancel%20order#orders_cancel
I have create the basics of subscription Paypal using the RailsCast and now I'm doing what is missing there.
Now I'm developing the process to do the Devise user registration together/just after the payment is done. For now, I'm trying something like this and this.
As the RailsCast got the e-mail from PayPal using this line:
#subscription.email = PayPal::Recurring.new(token: params[:token]).checkout_details.email
So, I thought that I could get first name, middle name and last name from PayPal as well. From PayPal documentation it seems that it is possible but I couldn't get it through paypal-recurring gem.
I have tried to see if I can learn what I have to do from paypal-recurring GitHub docs and code but I couln't find and tried some possibilities without success.
Is it possible? Maybe in another way not using paypal-recurring gem?
If you have another recomendation/reference to do this registration process, please, let me know.
Update
As #Andrew suggested PayPal IPN, I thought it would be better update my question as I want to have the first_name from PayPal as a default value to ease the process to the user register in my database but he or she may want to change to another name.
The process that I want is something like:
The user chooses his plan and to pay with PayPal
User is sent to PayPal
User fills payment info on PayPal site
User is sent again to my site
My site gets e-mail and name of the user from PayPal and asks the user to confirm or change the data, and provide his password to create the login to my site
My site uses the user data provided to register the user and sends the request to PayPal to request the payment and create the recurring profile
Ok, based on your current outline of steps you can handle that exact flow using Express Checkout.
SetExpressCheckout will generate a token for you, and you then redirect the user to PayPal. They review and approve the payment and are then redirected back to your site. There you can call GetExpressCheckoutDetails to obtain the email, name, address, etc. and display a final review page for the customer to confirm everything or make changes if necessary. Finally, you'd call DoExpressCheckoutPayment to finalize the payment using the customers confirmed details.
I would look at PayPal IPN (Instant Payment Notification). It'll POST transaction details to a listener script you have sitting on your server so you can process the data accordingly in real-time.