# FAQ & Support
source: https://developer.mastercard.com/automatic-billing-updater/documentation/support/index.md

## Frequently Asked Questions: About ABU {#frequently-asked-questions-about-abu}

ABU enables issuers to efficiently communicate account number changes and/or expiration date updates to reduce preventable card-not-present (CNP) declines with card-on-file and recurring payment merchants. ABU maintains a global data repository of account data (PANs and expiry dates). Registered merchants use this information to update their associated account billing records to significantly reduce the number of CNP authorization requests that get declined because of reissued cards or old expiration dates.

* Cardholder establishes an account-on-file payment arrangement with their merchants by giving their account number, expiration date and permission to be billed automatically by their merchants in the future.
* Issuers send account updates to the ABU data repository.
* The merchant's stored account data is compared against the ABU global data repository, and they receive account lifecycle updates to use for future digital or recurring payment transactions for any of the stored accounts found in ABU.
Cardholders are increasingly storing their account credentials with their card-on-file and/or recurring payment merchants for future card-not-present (CNP) transactions. When card numbers and expiration dates change, ABU helps ensure that corresponding CNP transactions will successfully process.

* For merchants -- reduces cart abandonment for digital shopping experiences and customer attrition risk due to involuntary churn for subscription and recurring billing businesses, improves funds collection and improves CNP authorizations and operational efficiencies
* For acquirers -- ensures improved merchant support, reduces CNP transaction declines and helps attract and maintain merchant relationships
* For consumers -- provides greater convenience and a seamless experience at preferred merchants
* For issuers -- helps keep the issuer's card top-of-wallet by reducing preventable CNP declines and the risk of payments converting to another payment type

## Frequently Asked Questions: Participating in ABU {#frequently-asked-questions-participating-in-abu}

Yes, all merchants, payment facilitators, and submerchants must be registered prior to sending ABU API calls. See the [ABU Reference Guide](https://techdocs.mastercard.com/bundle/m_MAB/) on Mastercard Connect Technical Resource Center for information on how to register merchants.
Note: Mastercard acquirers must register merchants and submerchants with the same merchant IDs (MIDs) as populated in DE 42 (Acceptor ID) of a Mastercard authorization request whenever a transaction is made at this merchant location. Yes -- To obtain ABU API updates merchants must first be registered. Registration can be done through the following methods:

* R625 ABU Merchant Registration bulk file -- this is the recommended method for registering standard merchants that do not have submerchants. See the [ABU Reference Guide](https://techdocs.mastercard.com/bundle/m_MAB/) on Mastercard Connect Technical Resource Center for file specifications
* ABU Merchant Management Form (form 673) -- this form is for registering standard merchants that do not have sub-merchants
* ABU Payment Facilitator Form (form 1164) -- this form is used to register a payment facilitator (aggregator)
* ABU Sub-Merchant Registration File (Microsoft Excel file for form 1164) -- this file is used in conjunction with Form 1164, and it is used for registering submerchants for the Payment Facilitator (aka aggregator)\*

Note: Forms 673 and 1164 are available from the Mastercard Connect [Forms Library](https://w201.mastercardconnect.com/gcccic001/homememb/library/shared/Forms_Library/Forms.htm) and will also be provided as part of your ABU project by your Mastercard implementation manager.

### Push subscription model {#push-subscription-model}

Subscriptions remain active as long as the underlying account remains active and available in ABU. A subscription may be deleted if the account is expired for longer than 13 months and the issuer did not provide a lifecycle update event for the account, or if the account has been deleted from ABU, for example at a cardholder's request.

Tip: Deleting a merchant ID from ABU does not automatically purge any account subscriptions associated with the deleted merchant. ABU will continue sending account update notifications to the ABU integrator's defined API endpoint. As soon as ABU processes an update for an account you have subscribed to, we send a push notification to your designated endpoint. No, ABU does not support push notifications for account updates on Mastercard Digital Enablement Services (MDES) network tokens at the moment. We are exploring this capability and may offer it in future.

## Frequently Asked Questions: Integrating with ABU APIs {#frequently-asked-questions-integrating-with-abu-apis}

Yes, a single client ID can be used for multiple ICAs for the ABU APIs.

* **First time ABU API production access requests**: Submit your production client ID request with all of your ICAs enrolled in ABU to be associated with the client ID. When making ABU API calls your ICA must be included in the request payload.

* **Existing ABU API users:** To add more ICAs to your existing ABU API client ID you will need a project with the Mastercard Customer Implementation Services (CIS) team.
  Please download the ABU Customer Enrollment Form (form 806, 806c, 806e, or 806i as applicable) from Mastercard Connect [Forms Library](https://w201.mastercardconnect.com/gcccic001/homememb/library/shared/Forms_Library/Forms.htm) and submit it to the email address listed on the form. The CIS team will open a project to implement the ICAs and also add them to your existing production client ID being used for the ABU API.

If you do not have access to Mastercard Connect, contact [abu_helpdesk@mastercard.com](mailto:abu_helpdesk@mastercard.com) or your Mastercard representative.
Tip: When making ABU API calls your ICA must be included in the request payload. Make sure your ICA has been enrolled in ABU through a Customer Implementation Services project before initiating an API call. API requests made without an ABU-enrolled ICA will result in a failure. Note: Each client ID only supports one Uniform Resource Identifier (URI) value, which ABU uses to identify the endpoint destination for sending push notifications. If you use the same client ID for multiple ICAs participating in the **Push subscription model**, ABU will send all notifications for all ICAs to the same endpoint. This is possible only if you are implementing the **Pull inquiry model** . You may establish multiple connections with ABU using the same ICA. Inform your Mastercard implementation project manager of all the client IDs you wish to onboard to ABU. You may then use any of the client IDs to make account inquiries.

ABU only supports one client ID per ICA in the **Push subscription model** in order to properly identify which accounts you have subscribed to and which endpoint ABU should send push notifications to.
ABU Pull inquiry model uses OAuth 1.0 protocols for the ABU API.

No - As the REST API and the JSON RPC API are within the same service, customers can use their existing Project and keys for the REST API. Customers will need to download the REST API specification file and configure their API client accordingly.   
Please note that the JSON RPC API will be deprecated in June 2024, so customers should be using the REST API by this time.

ABU Push subscription model uses a combination of OAuth 1.0 and mutual TLS authentication (mTLS) protocols for ABU APIs. Subscription management use cases, where you make an API request call to ABU to subscribe, unsubscribe, or check the status of a subscription, leverage OAuth 1.0. Notifications sent from ABU use mTLS.

More information on OAuth 1.0 for Mastercard APIs can be found [here](https://developer.mastercard.com/platform/documentation/authentication/). Information about mTLS is available [here](https://developer.mastercard.com/platform/documentation/security-and-authentication/using-mtls-to-access-mastercard-apis/).

### Push subscription model {#push-subscription-model-1}

If customers have already onboarded to ABU Pull and have an existing client ID, they do not need to create a new project and new client ID to use ABU Push. The same Client ID can be used for both models. Mutual TLS authentication (mTLS) is used for transport and authentication. Mastercard API gateway will present itself with the Mastercard certificate (signed by DigiCert). It will establish a TLS connection between one of the Mastercard IP addresses and your server at the configured URL. If you do not accept the TLS connection, there will be a delivery failure on Mastercard's side and you will not be able to receive the payload. We recommend customers add certificate authorities (CAs) from DigiCert, which can be publicly obtained from [DigiCert](https://www.digicert.com/kb/digicert-root-certificates.htm), to your keystores.

More information on mTLS can be found [here](https://developer.mastercard.com/platform/documentation/security-and-authentication/using-mtls-to-access-mastercard-apis/).
Like the first request, you will receive a `Valid` response with a HTTP status code 202 for another subscription request with the same information. Customers will receive a single notification in the event of an update where they have sent duplicate subscription requests. The `requestId` in the payload for account notifications that ABU sends in future will mirror the value provided in your most recent subscription request. The Mastercard API gateway generates this error when the maximum service limit for ABU Push is reached across all ABU Push customers. The TPS in the error message will not align with an individual client's TPS allocation. When you receive this error, please resubmit the account subscription request. ABU has different rules for reattempting to send notifications depending on whether the subscribed account is an MDES tokenized account or a non-tokenized account. For more information on the retry policy, refer to the relevant section in \[API Reference\] (/documentation/api-reference/#notifications-api)

## Get Help {#get-help}

Questions specific to API setup, connectivity, or key renewal can be sent to [APISupport@mastercard.com](mailto:APISupport@mastercard.com).

To find out more about onboarding to ABU, reach out to [abu_onboarding@mastercard.com](mailto:abu_onboarding@mastercard.com) or contact your Mastercard representative.

General ABU support questions can be sent to [ABU Helpdesk](https://www.mastercardconnect.com/case-mgmt/) by creating a case in the Support Case Management application on Mastercard Connect.

### Contact us for technical support. {#contact-us-for-technical-support}