# Accounts

Some operations in this section are similar to each other, but are
provided for different use scenarios. You should choose the one that best suits
your needs.


For example, the [Retrieve an account](https://developer.zuora.com/v1-api-reference/api/operation/GET_Account/) operation retrieves the basic information of an account, such as bill-to and sold-to contacts, billing and payments setup information, and metrics data for the account.

The [Retrieve an account summary](https://developer.zuora.com/v1-api-reference/api/operation/GET_AccountSummary/) operation returns the more detailed information of an account, such as bill-to and sold-to contacts, subscriptions, invoices, payments, and usages associated with this account.


## Create an account

 - [POST /v1/accounts](https://developer.zuora.com/v1-api-reference/api/accounts/post_account.md): Creates a customer account with a payment method, a bill-to contact,
and optional sold-to and ship-to contacts. Request and response field descriptions and sample code are provided. Use this operation to optionally create a subscription,
invoice for that subscription, and collect payment through the default payment method. The transaction is atomic; if any part fails for any reason, the entire
transaction is rolled back.
 
This operation is CORS Enabled, so you can use client-side Javascript to invoke the call.
 
### Notes

1. The account is created in active status.  
2. If the autoPay field is set to true in the request, you must provide one of the paymentMethod, creditCard, or hpmCreditCardPaymentMethodId
field, but not multiple. The one provided becomes the default payment method
for this account. If the credit card information is declined or cannot be verified,
no account is created.
3. Customer accounts created with this call are automatically
be set to Auto Pay.
4. If the invoiceDeliveryPrefsEmail field is not specified
in the request, the account's email delivery preference is always automatically
set to  false, no matter whether the  workEmail  or  personalEmail  field
is specified.
 
### Defaults for customerAcceptanceDate and serviceActivationDate

Default values for customerAcceptanceDate and serviceActivationDate are set as follows.

|        | serviceActivationDate(SA) specified          | serviceActivationDate (SA) NOT specified  |
| ------------- |:------------- | :-----|
| customerAcceptanceDate (CA) specified| SA uses value in the request call; CA uses value in the request call| CA uses value in the request call;SA uses CE as default |
| customerAcceptanceDate (CA) NOT specified      | SA uses value in the request call; CA uses SA as default |   SA and CA use CE as default |

This call supports a subset of the functionality of our Create an order call. 
For use cases where you create a subscription and a billing account at the same time, we recommend using "Create an order" instead of this call.
The Orders call has the following advantages: 
- Provides options for managing the entire subscription lifecycle from creation through to cancellation using different order actions. 
- Allows the creation or modifying of multiple subscriptions in a single order. 
- Allows a single order to combine both recurring subscription digital goods or services with order line items for physical goods.
- Orders are treated as atomic transactions. If any part fails, the entire order, subscription, and billing account creation are rolled back.

You should use this call if you need to create a standalone billing account, and create orders, subscriptions, standalone invoices, or dynamic usage charges later.
There are no deprecation plans for this call and we will continue to support this call for existing users.

## Delete an account

 - [DELETE /v1/accounts/{account-key}](https://developer.zuora.com/v1-api-reference/api/accounts/delete_account.md): Deletes a specific account asynchronously. 

Notes and Limitations: 
- For account deletion, the system will start a backend job to remove all transactions under the accounts and change the status of the accounts to 'Cancelled'. This backend job is asynchronous and will take some time, depending on the job size.  
- An account cannot be deleted when the account is either the invoice owner or the subscription owner of a subscription and the subscription's invoice owner and subscription owner are two different accounts. An exception to this limitation is if the Enable Force Deletion for Account? setting is set to Yes, you can force delete an account that is the subscription owner of a subscription while the invoice owner is a different account. Force deleting this account deletes all its subscriptions, but the relevant invoices will not be impacted.
- An account cannot be deleted if this account has ever been involved in an Owner Transfer amendment or order action, either as the current owner or as the previous owner.

## Retrieve an account

 - [GET /v1/accounts/{account-key}](https://developer.zuora.com/v1-api-reference/api/accounts/get_account.md): Retrieves basic information about a customer account.

This operation is a quick retrieval that doesn't include the account's subscriptions, invoices, payments, or usage details. Use Get account summary to get more detailed information about an account.

## Update an account

 - [PUT /v1/accounts/{account-key}](https://developer.zuora.com/v1-api-reference/api/accounts/put_account.md): Updates a customer account by specifying the account-key.

### Notes
1. Only the fields to be changed should be specified.  Any field that is not included in the request body will not be changed.
2. If an empty field is submitted with this operation, the corresponding field in the account is emptied.
3. Email addresses: If no email addresses are specified, no change is made to the email addresses or to the email delivery preference. If either the personalEmail or workEmail of billToContact is specified (or both), the system updates the corresponding email address(es) and the email delivery preference is set to true. (In that case, emails go to the workEmail address, if it exists, or else the personalEmail.) On the other hand, if as a result of this call both of the email addresses for the account are empty, the email delivery preference is set to false.
4. The Bill To, Sold To, and Ship To contacts are separate contact entities. However, if you set the soldToSameAsBillTo field to true when creating an account, the Bill To and Sold To contacts will refer to the same contact entity. As a result, updating either contact will update both. The same behavior applies to the shipToSameAsBillTo field and the Ship To contact. In this case, if you want to update only one of the contacts, you must create a new contact and then update the Bill To, Sold To, or Ship To contact to reference the newly created one.

## List payment methods of an account

 - [GET /v1/accounts/{account-key}/payment-methods](https://developer.zuora.com/v1-api-reference/api/accounts/get_acountpaymentmethods.md): Retrieves the payment methods of the specified customer account.

Note: This operation also supports retrieving custom payment methods created through the Open Payment Method service.

## Retrieve configuration of cascading payment methods for an account

 - [GET /v1/accounts/{account-key}/payment-methods/cascading](https://developer.zuora.com/v1-api-reference/api/accounts/getaccountpaymentmethodcascading.md): Zuora provides the Cascading Payment Method feature to dynamically retry the failed payment with alternative payment methods according to a predefined priority list. Use this API operation to retrieve the configuration information for Cascading Payment Method of a specified account, including the cascading consent value and the priority list of payment methods.

Before you use this API operation, ensure that the Cascading Payment Method feature is enabled. For more information about the Cascading Payment Method feature, see Cascade payment methods.

## Configure cascading payment methods for an account

 - [PUT /v1/accounts/{account-key}/payment-methods/cascading](https://developer.zuora.com/v1-api-reference/api/accounts/putaccountpaymentmethodcascading.md): Zuora provides the Cascading Payment Method feature to dynamically retry the failed payment with alternative payment methods according to a predefined priority list. Use this API operation to configure the cascading consent for a specified account and set up the priority list of payment methods to be used in Cascading Payment Method.

Before you use this API operation, ensure that the Cascading Payment Method feature is enabled. For more information about the Cascading Payment Method feature, see Cascade payment methods.

## Retrieve the default payment method of an account

 - [GET /v1/accounts/{account-key}/payment-methods/default](https://developer.zuora.com/v1-api-reference/api/accounts/get_acountdefaultpaymentmethod.md): Retrieves the default payment method of the specified customer account.

Notes: This operation also supports retrieving the custom payment method created through the Open Payment Method service.  This operation only works with an electronic payment method and does not work with non-electronic payment methods.

## Retrieve an account summary

 - [GET /v1/accounts/{account-key}/summary](https://developer.zuora.com/v1-api-reference/api/accounts/get_accountsummary.md): Retrieves detailed information about the specified customer account.

The response includes the account information and a summary of the account’s subscriptions, invoices, payments, and usages.

### Notes
Returns only the six most recent subscriptions based on the subscription updatedDate. Within those subscriptions, there may be many rate plans and many rate plan charges. These items are subject to the maximum limit on the array size.