Let's say that customer has single credit card (paymentMethod) bound to his account and he starts (buys) subscription to monthly plan with 30 day trial.
I would like to allow user to manage his credit card: delete it, add new (after deleting old card) and change it (delete+create new, actually).
The problem is that, AFAIK, when credit card is deleted then all subscriptions bound to it are also deleted. So theoretically user could delete his credit card just before trial expiration, add it again (same card) and "buy" same subscription again with another trial period.
Am I right? Is there anything I can do about it?
I work at Braintree. Feel free to reach out to support#braintreepayments.com with any further questions.
The easiest way to address this issue would be to not allow users to delete credit cards inside of the Vault, but only update their cards or cancel their subscriptions. Making a credit card update call means that your users can still change their card whenever they would like and the status of your subscription remains unchanged. For more information about how to update credit cards see the Braintree docs.
The other option would be to keep track of the uniqueNumberIdentifier of each credit card for each customer on your side. Then, before you create the subscription for a customer you can check the uniqueNumberIdentifier attribute of the payment method that you just created by reading it off the response and see if it matches any previous card associated with that customer. If yes, they are attempting to use the same card multiple times. The Braintree docs have more information about the attributes of the credit card object.
Related
Has anybody here dealt with incrementing subscriptions for "admin" users? Also, how do you handle invoicing and first/second-month charges in a neat manner?
I have a use case where users can sign up other subscribers and pay for these subscriptions from their card on file. The "admin" user signs up for the first subscription, and I keep incrementing the original sub every time a new sub is added.
When I send these through Cashier, the user only seems to get charged once, and then the second, third, etc., the first-month cost gets added onto the next month's invoice, and a new line item of unused time every time the admin user adds a new sub. So I first do:
$request->user()->newSubscription()->create();
Then I do:
$request->user()->subscription()->incrementQuantity();
The user only gets charged one monthly charge at newSubscription()->create(), And the next month's invoice has the following math.
(# of Subscriptions x Monthly Charge) - (Monthly Charge)
And the invoice has a ton of line items saying "Unused Time ..." which looks OK if that admin user only has one or two additions to their subscription but gets messy real quick beyond that. This seems super unprofessional and annoying to explain to the admin users. How do you/would you guys go about making this smoother? I understand that the invoicing for the incrementQuantity() method is enforced by the Stripe API, but it doesn't make sense to have so many prorating adjustments in a first invoice.
What is your goal/desired behavior here? Laravel cashier does allow you to change how you want the prorations to behave. By default prorations will be created and pulled into the next invoice, but you can also choose to disable prorations entirely or create prorations and have them immediately invoiced so that the difference is price is paid for immediately.
If you don't want any prorations generated at all when you update the quantity of a Subscription you can use noProrate() (see laravel's docs). Disabling prorations entirely may not be what you want though, since it won't allow you to charge a customer for the difference in price when they update mid-cycle. As an example, if you start off with a quantity: 1 Subscription they'll be charge for just 1 unit at the start of the month. If prorations are turned off and you update to quantity: 5, the customer won't have to pay for the new price until the subscription is renewed. If this is still what you want to do, you'd use it like this: $request->user()->subscription()->noProrate()-> incrementQuantity().
Another option would be to keep generating prorations, but have them immediately invoiced so that they aren't reflected in the renewal invoice at the end of the month. This will result in the customer being invoiced more often, but would solve your issue where the renewal invoice looks cluttered because of all the prorations. You would get this behavior by using alwaysInvoice() like this: $request->user()->subscription()->alwaysInvoice()-> incrementQuantity().
I need to let users choose to block a monthly recurring-bill.
Default subscription options are:
never_expires: true,
number_of_billing_cycles: nil
Is
never_expires: false,
number_of_billing_cycles: 0
the proper update to a subscription to accomplish that? Is 0 allowed as value for number of billing cycles? I want to update the subscription for a single user so that is not paying on the following month
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
You should be able to accomplish your goal through creating a discount. You'll need to create a discount associated with a plan via the Control Panel. However, via the API you'll be able to add a discount to the subscription. Specifically, you should create a discount on the subscription that equals the amount of the subscription in order to bypass a month.
Braintree doesn't really do this (at least, that I can tell...)
The way I would approach a 'free month' sort of thing is to simply do a refund for that month https://developers.braintreepayments.com/guides/recurring-billing/manage/php#refunding-a-subscription
I'm trying to create a recurring payment on Square, ala Stripe subscriptions. However, I am having trouble retrieving a customer's card information (specifically customer_card_id) to pass into Charge.
Our flow is such:
A customer visits to our store and subscribes to a membership, which we process via the point of sale app.
We continuously poll Square to retrieve payment information, and create membership records appropriately.
When the user's membership period expires, charge them for the next month's membership.
When researching RetrieveCustomer, I find that there is a cards property under Customer, but iterating through all the Customers under our account, they all have cards = None despite us having taken card payments via the point of sale app.
Also, looking at ListTransactions, there doesn't seem to be anything that might be customer_card_id. The IDs I see there are tender ID, location ID, and transaction ID. The card_fingerprint also looks promising but that doesn't seem right either, since a card can have both an ID and a fingerprint.
Am I missing something? Where might I find customer_card_id?
EDIT
Looks like I was dumb and my local instance of our application was just out of date with transactions from Square. After updating my data with customers we've processed since the last time I updated, customers with a non-None card property now show up. tristansokol's answer below is still valid however.
How do you process the first charge? You need to explicitly add the card on file, it won't be added by default from processing a transaction from a customer. See: https://squareup.com/help/us/en/article/5770-use-card-on-file-with-the-square-point-of-sale-app
Basically what I want to do is show a list of stored payment methods of the customer so they can pick an existing one instead of putting in credit card info.
I know I can store customerId and payment token in my server. But I need a way to present and map the token to some basic card info (such as Visa, last for digits, Name), so the user would know which is which. And upon user submitting the form, I need to know which token they've selected.
What's the best way of achieving this?
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
With a customer_id, you can call Braintree::Customer.find("customer_id") to get a Customer object, and then call customer.payment_methods to get the list of payment methods associated with that specific customer.
The list of attributes of each PaymentMethod object will differ depending on whether it is a credit card, PayPal account, or Apple or Android Pay Card. For example, you can find the attributes for a credit card payment method on this page.
Each PaymentMethod object will also have a token, so when the user selects one of the payment methods, you can use that token to create the transaction.
I have an app that uses Parse as its backend, and has Stripe integration. On Parse, I store a Stripe customer id on my User class, and I have a custom class that has a charge token associated with it, so that a customer can create a service request, and when a provider accepts and fulfills that request, they can have the charge be sent to their recipient id.
A user could cancel the service request, or a provider could show up to the user's property and find that the property is unserviceable for various reasons. In this event, we have a cancellation fee that the users are charged.
I want to make sure that if the cancellation fee is charged, it gets charged to the same card that the user used to request the service. I noticed that when I fetch all of the cards from a customer id, they always show up in the same order, but when I add a card, it doesn't always add it to the end of the array that gets returned when I fetch cards. So, if I just stored the index of the card, a user could add a new card, and it would possibly take the place of the one that was being charged for the service. If I charged a card based on the index for a cancellation, it could charge the incorrect card. Would it be PCI compliant to store the cardID used to create the charge token on the Parse object that contains information about the service, so when I call my functions to create cancellation charges, I'm charging the same card?
Thanks for anyone who can provide some information on this.
The only sensitive data that you want to avoid handling is your customers' credit card number and CVC; other than that, you're welcome to store any other information on your local machines.
As a good rule, you can store anything returned by our API. In particular, you would not have any issues storing the last four digits of your customer's card number or the expiration date for easy reference.
from: https://support.stripe.com/questions/what-information-can-i-safely-store-about-my-users-payment-information