For our use case, we have an existing form that captures the customer's credit card information. To smooth out the transition from one payment processor to the next since we're not sure when that will happen, we would like to vault the payment method in Braintree without charging the card but keep our existing form.
I see how to vault the nonce that we receive from the Drop-In UI, and I was able to find an answer on SO that described how to pass the payment information directly to Braintree and charging it, however, I have had no luck in finding a way to just pass the card information to braintree for the purposes of vaulting the payment method (with or without the intermediate step of receiving a nonce).
EDIT:
I've discovered the $gateway->customer()->create() and $gateway->creditCard()->create() functions, however, of the various 'unique identifiers' returned from the credit card create call, none of them appear to be vaultable.
It was buried a bit in the documentation, but I was able to do this with an intermediate step:
create customer $gateway->customer()->create(...)
create credit card $gateway->creditCard()->create(...)
take the token from the previous call and pass it to $gateway->paymentMethodNonce()->create(..)
then take the customer id and the newly created nonce and passed them to $gateway->paymentMethod()->create(...)
the necessary vault token was stored in the results object $result->paymentMethod->graphQLId
Related
I want to allow the customer to update their payment details used for a subscription, for example their card may expire or they may wish to use a new card.
If they have an active subscription I don't want to take a new payment from them yet obviously, so in this case is it sufficient to use Payment Method: Create to add the new payment method passing it the 3DS enriched nonce?
I know the amount which they will be charged so I can pass this amount to the 3DS challenge.
Will this payment method then be safe in terms of 3DS for any future charges for this subscription assuming the amount being charged goes no higher than the amount passed to the 3DS challenge?
Do I need to use Subscription: Update in any way or does setting the new payment method as default (using the makeDefault parameter when creating the payment method) guarantee that it will be used for the next payment on the subscription?
Answering my own question after figuring this out.
Using Subscription.Update is necessary, and you should pass it the 3DS enriched nonce.
It is not necessary to use Payment Method: Create, typically the recommend flow for updating a subscription would be:
Vault the new payment method (without 3DS)
Create a nonce from the newly Vaulted token
Run verifyCard on the nonce, to get a 3DS nonce
Run a Subscription.update() with the 3DS nonce (which references the Vaulted token)
For what it's worth I managed to still use the Dropin UI, for steps 1-2 then I used verifyCard in my code to initialise the 3DS challenge.
I have an issue with Braintree,
Suppose a customer logged in on my site, then I create client token for that customer (By passing customer id in Braintree\ClientToken::generate() function ),
so that if he have any existing payment method then it will be loaded automatically at client side.
But if customer selects new payment method which already in vault:
for card same card number, for Paypal same email address,
then it automatically added in vault for that customer, either it exists or not,
So in my case, i don't want to store same payment method(either Paypal or Card) twice or more for same user,
How can i restrict so that same payment method should not store multiple times in vault?
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact
support.
There is actually a parameter you can set in the Client Token generate options called failOnDuplicatePaymentMethod. If this option is passed as True and the payment method has already been added to the Vault, the request will fail. This can only be passed if a customer_id is passed as well. If the check fails, this option will stop the Drop-in from returning a payment_method_nonce. Unfortunately, this will not work for Paypal Payment methods, and there are a few workarounds for that.
Not Storing in the Vault
You would first need to collect the customer's PayPal email account in the client-side callback. When the payment type is a PayPalAccount , you can then run a Braintree::Customer.search() request on the user's email. If this brings up any customers that have the PayPal email account you specified (which was retrieved from the client-side integration), you wouldn't need to vault the account, you can simply proceed with creating another transaction on the existing token.
Deleting Duplicate Accounts
The second workaround is similar to the first.You collect the customer's PayPal payment method as usual (collect the nonce and pass it to your server) and then use it in a Braintree::PaymentMethod.create or Braintree::Customer.create API request as usual. In the result object returned, you can then check the details of this PayPal transaction, paypal_details and inspect this to find the email address. If this email matches one for a PayPal account for that customer, you can choose to delete the new payment method immediately.
Don't hesitate to reach out to Braintree Support if you need more help.
Is it possible to associate a one-off Stripe charge/payment with a Stripe Customer profile but not save the card to the profile? I'd really like to organize my Customers and their purchases within the Stripe dashboard, but I can't see any way to do this. From what I can tell there are three ways to create a payment:
Using the source parameter and no customer parameter. The source parameter in this instance starts with tok_
Using the customer parameter, which will use the default card on file.
Using the customer and source parameters, where source is the card ID associated with the customer starting with card_.
I've looked through the docs and can't see anything that alludes to being able to create a payment using customer and a tok_ source. Am I missing something here?
This is not supported by Stripe at the moment. You can still do this though with a few steps:
You create a card token
You add the card to a customer
You charge that card
You delete the card from the customer
This ensures that you don't save the card but still have the charge associated with the right customer.
Is it possible to make Paypal payments using stored user's data (credit card info, name, address etc.) within cron job or other script execution without actual user present?
I want to implement autopayments on my service but I can not to use standard Paypal autocharge functionality because of its complexity.
What you're looking for is called Reference Transactions. You can use the DoReferenceTransaction API to accomplish your goal.
Using this API you simply pass in the transaction ID of a previous Authorization or Sale transaction along with a new amount you'd like to process. It will lookup the billing info saved on PayPal's system using that previous transaction ID, and then process the same source for the new transaction.
This works with both Payments Pro and Express Checkout.
I noticed you posted this with the adaptive payments tag, too. That would be the Preapproval API and the Pay API, but would not involve DoDirectPayment.
Let's say, for the sake of discussion, my client does not want to use the Paypal api for transactions. I have already made a shopping cart. The user submits the items on the shopping cart and their credit card number.
Assuming I'm not using any api, how would I then charge the user's credit card for the items on the shopping cart? I understand that it is complex, just wondering what the general process is like and how to get started.
You're going to need to trigger a bank transaction, so obviously you're going to need to use an API at some level. I think the way to go would be to first learn in some detail how at least one of the popular commercial (by definition?) payment card processing services works, e.g.:
https://paymentvision.com/Payment-Gateway/Payment-Gateway-API.aspx
http://aws.amazon.com/fps/
https://www.firstdata.com/en_us/customer-center/merchants/support/first-data-global-gateway-api-software-landing.html
http://www.authorize.net/
The next step would be to design the "payment processing" subsystem of your PHP application/library around the "backend workflow" (perhaps using a 3rd party PHP library, if one is available), and do some testing.
Then I would plan for a security audit of your code & systems before you actually use it to handle payment card information on behalf of a customer/3rd party.
You can also capture all the card information and use an external payment processor. The problem is that you will be hit with major fees since it will be considered a keyed in and not swiped transaction.
If you don't want/like paypal, don want to use a payment processor like authorize.net, you could look at other options like stripe.com.
Find an payment gateway, such as authorize.net. With payment gateways such as this, your client will need to sign up for a merchant account with a credit card processing agency. You payment gateway can help you with this.
Then, you'll usually get a token or api key that you will use to connect to the payment gateways services. From php, you'll use cURL or fsockopen to connect to them. Securely send your api key, get a response, then send some other required message, get another response, and then send in credit card information and credit card holder information.
There are lots of PHP Libraries to choose from out there for different payment gateways. I'm not suggesting authorize.net, it was just an example. But when you find one you are happy with, and happy with the fees that are associated with processing credit cards, you can either use a prewritten library, or they payment gateway will provide you with and API that will tell you how to integrate with their system.
Payum efficiency proved by 1k+ stars on a GitHub, great comments and a million of downloads. Supports 50+ different payment gateways so you surely find what you need.