Customer
Customer: Update
See also the Customer response object.
To update a customer, use its ID along with new attributes. The same validations apply as when creating a customer. Any attribute not passed will remain unchanged.
- Ruby
result = gateway.customer.update(
"a_customer_id", # id of customer to update
:first_name => "New First Name",
:last_name => "New Last Name"
)
if result.success?
puts "customer successfully updated"
else
p result.errors
end
Arguments
id
required, StringAdditional Parameters
:company
String:company
String:country_code_alpha2
StringThe ISO 3166-1 alpha-2 country code specified in an address. The gateway only accepts specific alpha-2 values.
:country_code_alpha3
StringThe ISO 3166-1 alpha-3 country code specified in an address. The gateway only accepts specific alpha-3 values.
:country_code_numeric
StringThe ISO 3166-1 numeric country code specified in an address. The gateway only accepts specific numeric values.
:country_name
StringThe country name specified in an address. We only accept specific country names.
:extended_address
String:first_name
String:country_code
String:national_number
String:last_name
String:locality
String:update_existing
bool:phone_number
StringDeprecated.
We recommend using international_phone
. This functionality still exists in the gateway but is no longer documented. This parameter will be removed in the future.
:postal_code
String:region
String:street_address
String:billing_address_id
String:cardholder_name
String:cvv
StringTypically requires PCI SAQ D compliance
We recommend using payment_method_nonce
to avoid any PCI concerns with raw credit card data being present on your server.
A 3 or 4 digit card verification value assigned to a credit card. The CVV will never be stored in the gateway, but it can be provided with one-time requests to verify the card.
:expiration_date
StringWhile we recommend using payment_method_nonce
when updating raw credit card data, the expiration date can be updated directly without any PCI concerns as long as you do not store, process, or transmit the raw PAN or CVV.
The expiration date, formatted MM/YY
or MM/YYYY
. May be used instead of expiration_month and expiration_year.
:expiration_month
StringWhile we recommend using payment_method_nonce
when updating raw credit card data, the expiration month can be updated directly without any PCI concerns as long as you do not store, process, or transmit the raw PAN or CVV.
The expiration month of a credit card, formatted MM
. May be used with expiration_year, and instead of expiration_date.
:expiration_year
StringWhile we recommend using payment_method_nonce
when updating raw credit card data, the expiration year can be updated directly without any PCI concerns as long as you do not store, process, or transmit the raw PAN or CVV.
The two or four digit year associated with a credit card, formatted YYYY
or YY
. May be used with expiration_month, and instead of expiration_date.
:number
StringTypically requires PCI SAQ D compliance
We recommend using payment_method_nonce
to avoid any PCI concerns with raw credit card data being present on your server.
The 12-19 digit value on a credit card consisting of a bank identification number (BIN) and primary account number (PAN).
:make_default
boolIf the payment method is a credit card, prevents the verification from being evaluated as part of Premium Fraud Management Tools checks. Use with caution – once you've skipped checks for a verification, it is not possible to run them retroactively.
:update_existing_token
String:verification_amount
StringSpecify the merchant account ID that you want to use to verify a card. Can't be a Braintree Marketplace sub-merchant account. For more details on merchant accounts in general, see merchant_account_id
on Transaction: Sale
.
:verify_card
boolIf the payment method is a credit card, this option prompts the gateway to verify the card's number and expiration date. It also verifies the AVS and CVV information if you've enabled AVS and CVV rules.
In some cases, cardholders may see a temporary authorization on their account after their card has been verified. The authorization will fall off the cardholder's account within a few days and will never settle.
Only returns a Credit Card Verification
result if verification runs and is unsuccessful.
Results of a merchant-performed 3D Secure authentication. You will only need to use these fields if you've performed your own integration with a 3D Secure MPI provider (e.g. Cardinal Centinel). Otherwise, Braintree's SDKs handle this for you in our standard 3D Secure integration.
:cavv
StringCardholder authentication verification value or CAVV. The main encrypted message issuers and card networks use to verify authentication has occurred. Mastercard uses an AVV message and American Express uses an AEVV message, each of which should also be passed in the cavv parameter.
:ds_transaction_id
StringTransaction identifier resulting from 3D Secure 2 authentication. This field must be supplied for Mastercard Identity Check.
:eci_flag
StringThe value of the electronic commerce indicator (ECI) flag, which indicates the outcome of the 3DS authentication.
Accepted values for Mastercard:
00
= Failed or not attempted01
= Attempted02
= Success04
= Data-Only (Applies to limited processors)
Accepted values for all other card brands:
07
= Failed or not attempted06
= Attempted05
= Success
:three_d_secure_version
StringThe version of 3D Secure authentication used for the transaction. Required
on Visa and Mastercard authentications. Must be composed of digits separated
by periods (e.g. 1.0.2
).
:xid
StringTransaction identifier resulting from 3D Secure authentication. Uniquely identifies the transaction and sometimes required in the authorization message. Must be base64-encoded. This field will no longer be used in 3D Secure 2 authentications.
:token
StringAn alphanumeric value that references a specific payment method stored in your Vault. Must be less than or equal to 36 characters. If using a custom integration, you can specify what you want the token to be. If not specified, the gateway will generate one that can be accessed on the result. If using our Drop-in UI with a customer ID to vault payment methods, you can't specify your own token. Length and format of gateway-generated tokens and IDs may change at any time.
A collection of custom field/value pairs. Fields and values must be less than 255 characters. You must set up each custom field in the Control Panel prior to passing it with a request. Querying this value returns a collection of custom field values stored on the customer object.
:device_data
StringCustomer device information. Pass this value only if you have Premium Fraud Management Tools enabled and are adding credit card data to your Vault. Be sure to provide the full string received from the Braintree client SDK.
:email
String:fax
String:first_name
String:id
String:country_code
String:national_number
String:last_name
String:payment_method_nonce
String:phone
StringDeprecated.
We recommend using international_phone
. This functionality still exists in the gateway but is no longer documented. This parameter will be removed in the future.
:tax_identifiers
array:country_code
StringThe ISO 3166-1 alpha-2 country code specified in an address. The gateway only accepts specific alpha-2 values.
:identifier
String:website
StringExamples
Update customer and existing credit card
To update an existing credit card when using the customer update method, you need to pass the token of the credit card under the credit card options.
- Ruby
result = gateway.customer.update(
"a_customer_id", # id of customer to update
:payment_method_nonce => nonce_from_the_client,
:email => "new.email@example.com",
:credit_card => {
:options => {
# token of credit card to update
:update_existing_token => "the_token"
}
}
)
If you are only storing the customer ID in your system and using a 1:1 model of customer to credit card, then you can get the token for the credit card from the customer details.
- Ruby
customer = gateway.customer.find("a_customer_id")
token = customer.credit_cards[0].token
Update customer, credit card, and billing address
The billing address can also be updated by adding in the billing address details and setting the update_existing option in the billing address attributes.
- Ruby
result = gateway.customer.update(
"a_customer_id",
:payment_method_nonce => nonce_from_the_client,
:email => "new.email@example.com",
:credit_card => {
:options => {
:update_existing_token => "the_token",
},
:billing_address => {
:street_address => "New Street Address",
:postal_code => "60622",
:options => {
:update_existing => true
}
}
}
)
If you omit the update_existing valoption under the billing address, we will create a new address for the customer and associate it to the credit card. The old address will remain associated to the customer but no longer associated as the billing address of the credit card.
Update customer and create new payment method
You can add a new payment method to an existing customer using the customer update API.
Credit card
If you omit the update_existing_token valoption from the examples in the previous sections, a new credit card will be created and associated to the customer.
- Ruby
customer = gateway.customer.find("the_customer_id")
customer.credit_cards.size
#=> 1
result = gateway.customer.update(
customer.id,
:payment_method_nonce => nonce_from_the_client
)
if result.success?
result.customer.credit_cards.size
#=> 2
end
Any payment method type
You can use a payment method nonce for any payment method type—not just a credit card—to associate that payment method to the customer. The example below shows adding a payment method while also updating customer details.
- Ruby
result = gateway.customer.update(
"a_customer_id", # id of customer to update
:payment_method_nonce => nonce_from_the_client,
:email => "new.email@example.com",
)
Update default payment method
To update a customer's default payment method, get that payment method's token and pass it as the default_payment_method_token value below:
- Ruby
result = gateway.customer.update(
"a_customer_id",
:default_payment_method_token => "the_token"
)
Card verification
By default we will run credit card validations but not perform verification. Braintree strongly recommends verifying all cards before they are stored in your Vault by enabling card verification for your entire account in the Control Panel. If you choose to manually verify cards, set verify_card to true.
- Ruby
result = gateway.customer.update(
"a_customer_id",
:payment_method_nonce => nonce_from_the_client,
:credit_card => {
:options => {
:update_existing_token => "the_token",
:verify_card => true
}
}
)