MID

What is a MID (Merchant Identifier)?

Let's start by defining what a Merchant ID is:

"A unique identification number sequence associated with a physical or online merchant location, typically allowing payment processors involved in a transaction to know where to send which funds. It’s effectively an address within the payment ecosystem. Without a merchant ID, the networks involved won't know where to send the merchant's money."

‍To put it simply a merchant ID or (MID) is Merchant Identification Number.

This is a unique code provided to a merchant by their payment processor. Often abbreviated as MID, this code is transmitted along with the cardholder information to involved parties for transaction reconciliation.

Locate a MID

Where can you locate a Merchant ID? 👀

Merchants can typically find their merchant identification number on their billing statement from their payment processor. If a client has a close relationship with their merchants and feel comfortable doing so they can point them toward their payment processor and ask them to locate their MID, explaining that having it will expedite the onboarding process with Fidel. Another place merchant have access to their MID is within their payment processor's online merchant portal.

Different Card Brands use unique MIDs.

Mastercard and Visa refer to this unique number as the MID.

Amex's equivalent to a MID is called a Service Establishment Number.

MIDs format

What do MIDs look like?

MIDS or Merchant ID’S are not issued by Fidel API and therefore we do not have any control over the format of these identifiers. There is no real uniformity with MIDS but there are some general rule of thumbs we can take away:

• No less than 5 chars or no longer than 15 chars;
• Can certainly be alphanumeric for example Stripe issues MIDS which are usually alphanumeric strings;
• In the case of Payment Facilitators, expect multiple merchants to be using the same one.

Payment Processor

What is a Payment Processor? 🧾

The payment processor (like Stripe, SumUp etc.) manages the card transaction process by acting as the mediator between the Merchant and the financial institutions involved.

When you insert, tap, swipe or even type your card number in to pay for something that triggers the creation of an auth, (short for authorization).

The merchant's point of sale (POS) software sends this auth through their payment processor who acts as an intermediary for the merchant's payment software system to access the credit card networks and be able to accept credit cards as a form payment.

The auth is a payment event that sends a quick call for verification through to the issuing bank to see if the card is valid (not expired, lost or stolen) and that it has funds associated with it.

This request goes to the credit card's issuing bank (where the cardholder got the line of credit from) and returns instantly either an "approve" or "decline" response that is sent back through the payment processor to the merchant's payment software.

This entire process happens in just a matter of seconds. If the card gets approved and the transaction gets finalized and settled then the payment processor deposits the funds from that credit card transaction into the merchant's bank account.

As complex as this process is, it makes the ability to pay for things very convenient. In our increasingly digital world not accepting credit cards is like turning away money from people willing to spend it.

Helping Merchants Find their Payment Processor:

• To figure out who is processing their credit card payments merchants can look at their deposits that fund from their credit card transactions. In the description of the deposit it should identify who sent the funds. The funds will be sent from the payment processor the merchant is using.
• The payment processor is the keeper of the Merchant Identification Number or MID. 🔒
• The payment processor charges the merchants regular fees to be able to accept credit cards on behalf of themselves and the card brands. If a merchant has their statement regarding processing rates and fees for credit card transactions that statement should be from their payment processor and the MID (sometimes called merchant number) should be printed on it.

Why is a MID important?

When a Merchant consents to allow us to access their MIDs it gives us the ability to return higher levels of accuracy in the data we provide to our clients. Many times locations can be complex to track due to situations like malls or shopping centers where one physical street address can be the site of twenty, fifty or even hundreds of different individual stores.

MIDs become more valuable when it comes to specific locations that may contain thousands of transactions occurring in one day at one address, but thanks to the transactions going through specific MIDs they are safely connected to the store where the purchase was made.

A store with both a physical and online locations will have different MIDs for each. The transactions processed online are running through an entirely different MID than those processed within the physical store. This further breaks down the data accurately to specify where the transaction actually occurred.

Providing a MID during onboarding with Fidel can help to guarantee high match rates for transactions and locations, even in locations with high-turnover rates, and even on the busiest days of the year. Providing a MID during onboarding can also reduce the onboarding of the merchant to a single day.

Is it secure for me to share MIDs with Fidel?

At Fidel we understand that a MID is a very sensitive piece of information. We handle data compliant to PCI DSS regulations. We tokenize all of our data and assign it unassociated equivalent data elements that act as a reference point to the original data. The resulting outcome is a 'token' that disguises the original data but still allows the necessary information to communicate across and back to our clients securely.

At Fidel we use tokenization in many areas within our APIs, including how we send and receive transactional data in real-time with the major card networks. The MIDs are received by Fidel via our encrypted closed-loop API, which tokenizes the MIDs before they are collated into our secure dashboard.

🔐 Fidel passes MIDs directly to our network partners who have their own encryption processes for secure file transfers. Regardless of where the MID goes from there it's securely concealed in encryption language as the transaction data tokens we produce. The card network's own secure information transfer process further ensures that the information throughout its whole journey remains secure. Whenever that information is within our API, it is unreadable to anyone outside that circuit. Fidel makes a point of requesting that any information sent to us is done so via our API or SDKs to make sure that it's captured securely.

Location Sync failed

How do I resolve a location that has failed to sync?

In order to successfully onboard the location/s the answer to why it has failed to onboard will typically guide your approach in terms of resolution steps.

How can I programmatically set a location to syncing once it has been created via the API?

In order to sync a location at its creation, you are required to submit the below parameter. Failing to do this will result in the location reverting to an idle state and will mean that we don’t send the data to the card networks for onboarding unless you manually navigate to the dashboard to trigger the sync.

1{ "status": "syncing" }

Additional information can be found in the API Reference here.

Locations stopped tracking

I have received reports that a location has stopped tracking, how do I restart this?

There’s a number of reasons why this may have occurred, below are some information we will require to investigate:

• Has the location ever tracked a transaction? This is key as if the answer is no then it is likely that the MID was incorrect.
• When was the last time the location successfully tracked a transaction?
• Were there missing transactions from this location? If so, when is the transaction dated at. Not all merchants are set up to accept auth transactions, therefore a good rule of thumb is to wait 3-5 working days to allow a potential clearing to be received.

The most common reason for a location to stop tracking is the presence of a new MID/VSID (Visa Store Identifier), in a real world scenario this occurs when a merchant decides to use a new processing facility.

Please raise a support ticket with our support@fidel.uk for any further help.

New MID

I’ve obtained a new MID for one of my merchant locations, how can I add it?

There are a couple of ways to achieve this either via the Dashboard or through the API.

Note: A location must not be in sync on any card scheme before the below actions can be taken.

• Has the location ever tracked a transaction? This is key as if the answer is no then it is likely that the MID was incorrect.
• When was the last time the location successfully tracked a transaction?
• Were there missing transactions from this location? If so, when is the transaction dated at. Not all merchants are set up to accept auth transactions, therefore a good rule of thumb is to wait 3-5 working days to allow a potential clearing to be received.

The most common reason for a location to stop tracking is the presence of a new MID/VSID (Visa Store Identifier), in a real world scenario this occurs when a merchant decides to use a new processing facility.

Please raise a support ticket with our support@fidel.uk for any further help.

• Click the three dots icon on the far right which is present next to each individual location.

• Select the edit option

• On the widget that appears click on the Include a MID button. At this point you will be able to add your MID.

• When updating a location it will always revert to an idle state. It is critical that you trigger the changes by clicking on Sync Locations at the top right of the screen.

A developer can programmatically add a MID by following the below:

• Call updateLocation endpoint - Update Location
• You will need to add the same attributes as previous i.e. if the merchant address has not changed then the developer is required to submit that same information.
• You should also add the searchBy field with the value being the new MID
• As before, the user is required to sync the locations in order to trigger the changes. In addition they will also be required to go back to the dashboard and press Sync Locations.

Shared MIDs

Does Fidel support ‘Shared MIDs’?

All merchants who process transactions using a Payfac (Payment Facilitators) use a MID that is also used to process transactions by many other merchants.

Using a shared MID affects the ability to track transactions as shared MIDs do not always have unique identifiers which are necessary to differentiate which merchant locations the transactions were made at.

If a MID that is shared across multiple merchants was added to a single location then that location would track every transaction made at all locations sharing that MID. This would cause transactions that don’t belong to the business onboarded to be tracked to it. 😥

In addition, merchant consent is required for the ability to track a merchant’s transactions. As such, tracking transactions on a shared MID that doesn’t just belong to the merchant who has provided consent raises additional concerns surrounding merchant consent.

Fortunately, at Fidel API we have been able to distinguish additional identifiers with the card networks which do allow us to track most Payfac transactions, at least in the clearing or settlement state.

Below is a breakdown of what which Payfacs we can track in North America on which card networks:

Even with the progress we have made in tracking PayFacs in North America there are still a few Payfacs which are complete blockers as they do not contain unique identifiers to be able to parse out and track transactions specific to one location.

Below is a list of Payfacs in North America we can and cannot currently track at this time.

‍Note: while the list may not include every North American Payfac, it contains most major Payfacs we have encountered significant processing volume through.

Transaction data

What transaction data do I receive from Fidel? What is the frequency and method of receiving transaction data?

If you are using our ‘Select Product’:

Please see more details on what Transaction data you will receive for each transactions event as well as the transaction lifecycle here: Transactions Docs.

If you are using our ‘Offers as a Service (OaaS)’ product as a Content Provider:

Fidel receives the verified transaction data from OaaS publishers in batch (daily/ weekly/ monthly), we have a defined format and fields which our Publishers send the transaction data as, please see those here: Fidel API OaaS Readme.

You will be able to get transaction reporting on your offers via our Data Analytics tools called Metabase, where you can view but also download reports from. Please connect with your Fidel Business Development Lead on any more details here.

Missing transactions

A cardholder has reported a missing transaction to me, how can I get this investigated?

Please raise a support ticket by contacting either of the below:

• Email support@fidel.uk
• Raise a raise request at Zendesk

Please use below template

1Hi Fidel team, can you please find the MID for the following transaction:
2
3Location ID:
4Card ID:
5Transaction amount (with tip, don’t include currency symbol):
6Transaction date (without time - YYYY-MM-DD):
7Card scheme/network (visa, mastercard, amex):
8
9Many thanks,
10XXX

Refunds / Reversals

How does Fidel share refunded/ reversed transactions?

Please see more information on refunds here: Fidel API - Refund

How do I calculate how much cashback/reward to debit from the cardholder in the event of a partial refund?

Whilst we can track refunds and communicate these events (through the transaction.refund / transaction.refund.qualified webhook events) which includes the originalTransactionId (Fidel API - Refund), Fidel won’t know if a refund event shared with you was a ‘partial’ refund, however you will receive the originalTransactionId as part of the refund, which is the reference to the original transaction.

You will also receive (amongst others) the below data points:

• Card ID (The user who made the refund)
• Amount
• Merchant
• Date
• Cashback Amount (null as transaction is NOT qualified)
• Offer ID

This information allows you to call the cardholders transaction history within their own database.In order for you to calculate the cashback value from the refund based on the offer id, you can use our Offer API. More specifically, you can use this endpoint in order to retrieve the value.

Only clearing or auth received

Why has a transaction only been tracked in clearing or vice versa?

There are a number of reasons why this may occur but some typical reasons are as follows:

• Some acquirers will provide different MIDs for either/or the clearing and auth event of a transaction. Potentially one of these MIDs has been missed, if that is the case Fidel would not be able to track the relevant event;
• Transaction was performed at a ‘Shared MID’, please see more on this in Locations FAQ.
• Particularly in the case of auth, some retailers forgo this event completely as these events come at cost;
• Transaction was a ‘offline’ transaction and hence only the clearing was passed by the card network;
• Transaction was performed on a ‘co-badge’ card and processed on a domestic scheme.

'Offline' transaction:

Offline card payments transactions refer to when a customer uses their credit or debit card to make a purchase, but the transaction is not immediately authorized by the Issuer(Bank). Instead, the transaction is processed through a clearing system, where the merchant sends the transaction details to the bank for approval and settlement at a later time.

The reason there isn't an immediate authorization for offline transactions is because they typically occur in situations where the card cannot be verified in real-time, such as when the card reader is not connected to the internet (such as on planes, or on trains etc.). In these cases, the transaction is processed offline and the authorization is obtained through a clearing process later on. This allows the transaction to still go through even without immediate verification.

It could also be that the merchant has an agreed ‘floor-limit’, which is the maximum amount that a merchant will allow for offline transactions to be processed without requiring authorization from the card issuer. This is typically set by the merchant's acquiring bank and is meant to reduce the risk of fraud and chargebacks but also to reduce queuing or waiting time to process time (i.e. at Coffee shops, train ticket vendors/ vending machines etc.).

For example, if a merchant has a floor limit of $50, any offline transaction below that amount can be processed without needing to contact the card issuer for authorization.

Co-badge card transactions:

When a transaction is processed on a domestic scheme, such as a co-badge card transaction, it means that the transaction is being processed through a local payment network (i.e. UAESWITCH, Giro etc.) rather than a global card network like Visa or Mastercard. In these cases, the transaction may not require authorization from the card network because it is being processed within the same country or region where the card was issued.

However, even though the transaction may not require authorization from the card network, it will still go through a clearing.

So, while co-badge card transactions may not require authorization from the card network, they will still go through a clearing.

Apple Pay / Google Pay transactions

Can Fidel track transactions made through a digital wallet such as Google Pay or Apple Pay?

There are a number of reasons why this may occur but someFidel can track spend through digital wallets as long as the full PAN from the front of the card is enrolled. This is particularly important to note here as a digital wallet will tokenize the card number as a security measure and this is usually accessible to the cardholder.

If the cardholder were to enrol the virtual PAN (PAR), then Fidel would not be able to track that person’s spend. The onus is on the client to manage the messaging to their users around this topic. typical reasons are as follows:

VOIDs

Does Fidel track VOIDs?

• Amex - No.
• Mastercard - Yes. Mastercard sends files periodically with VOIDs.
• Visa - Yes. It is sent in the same way of normal refunds.

For the supported networks, Fidel sends the VOID to the publisher through the normal refund webhook so that publishers can then decide which process and business logic should be in place on their end.

Card details required

What card details need to be provided to Fidel to enrol a card?

If you are using our Create Card API, these are the required fields which need to be passed on to enrol a card:

• 3-digit Country code of the card issuing country
• Expiry Month and Year
• Card number (15 - 16-digit long)
• Acceptance of the Terms of Use or Cardholder consent

Please see more details on Create Card API Reference

Error messages on card enrolment

What are the different error messages Fidel will send me, on an invalid card enrolment?

Please see all error messages here: Create Card Error Messages

Card eligibility

Which cards does Fidel support?

Only Eligible Payment Cards may become Linked Cards. Please note that not all Visa, MasterCard and American Express cards are able to become Eligible Payment Cards. The Payment Cards not eligible to become Linked Cards are Visa, MasterCard, and American Express Corporate cards, Visa, MasterCard, and American Express Purchasing cards, non-reloadable prepaid cards, government-administered prepaid cards (including EBT cards), healthcare (including Health Savings Account (HSA) or Flexible Spending Account (FSA) or insurance prepaid cards), Visa Buxx, and Visabranded, MasterCard-branded, and American Express-branded cards whose transactions are not processed through the Visa payment system, MasterCard payment system, and/or American Express payment system, and any other type of card notified to you by Fidel API from time to time.

Fidel API and the Card Networks may in their sole and absolute discretion decide whether a Payment Card is eligible to become a Linked Card. Depending on the territory your registered debit card transaction must be processed as a 'credit' (i.e., authorized with signature and not a PIN) transaction to make sure the transaction can be monitored.

Apple Pay / Google Pay cards / virtual PANs

Can Fidel track cards added to digital wallets?

The answer is yes and no. Fidel can still track cards added to digital wallets such as Apple Pay and Google Pay as long as the physical PAN (i.e. long card number on the front of the card) has been enrolled. A digital wallet will tokenize the PAN information before sending your data to the merchant as a security measure. However, it has been tested previously that, as long as the physical PAN has been enrolled, Fidel will receive the transaction information.

User can't enrol card

Why are some cardholders unable to enroll their cards?

If a cardholder is unable to complete the enrollment process, it may be due to one of the following reasons (that were identified until now, more might exist):

• Issuer Restriction: Some card issuers have restrictions in place that may prevent enrollment. This is often a security or policy measure decided by the issuer or by the network itself. Example: Well Fargo credit card - Business Essential Mastercard. Wells Fargo asked Mastercard to not allow them to enroll this card on CLS (Mastercard Loyalty System used by Fidel).
• Digital-PAN/ PAR/ Token: It could be that the user has enrolled the tokenised PAN/ PAR instead of the actual long-number of the PAN, as that changes with every transaction, Fidel can not enroll these to Select Transactions API, as these are not static.
• Card might not be eligible for Loyalty/ Reward programs, please see section Card Eligibility

Please see more details on Apple/Google Pay cards

Card expired

What happens when my user's card expires? Are they required to re-enrol?

Fidel primarily tracks on the PAN (16 digit card card number). There are two scenarios here:

• Issuer sends new card with the same card number as before and new expiry date

In this scenario, the same card PAN will continue to exist, eliminating the need for the user to re-enter their details.

However, we would be returning the expiry date to you, so you know if the card has expired and you can ask the cardholder to update the date.

• Issuer sends new card number with new expiry date

In most cases, due to security, however the Issuer sends a new card number, in these cases the 'old card' will need to be deleted by you and the 'new card' to be re-enrolled, we recommend this process due to security reasons. You can use our Delete card APIDelete Card to delete the 'expired card' and ask the cardholder to 'enroll' their new card to the program.

In both cases, Fidel will receive transactions from the networks for both the old PAN (until it is deleted) and the new PAN (once enrolled), which we will continue to forward to you.

Identify user

I wish to be able to identify my user when they enrol their card

Fidel does not collect or store personal information however there is a clear rationale for clients having access to this to fully maximise the card linking information. On each card enrolment, the client has the option to pass additional metadata which will be received and returned back to the client endpoint exactly as it has been submitted. In addition to this, each transaction that tracks on the enrolled card going forward, the metadata will be returned as part of the transaction payload.

SDK or API

I see that I can send cardholder data through one of your SDKs or direct to API via the createCard endpoint. Which one is more suitable for me?

The answer lies largely in the clients use case and more specifically how they handle their user information. However, there are some key considerations to take into account.

createCard (API)

First and foremost, this endpoint ingests card data in its raw form i.e. full PAN, Expiry Date and Country of Issue. The usage of this endpoint dictates that the sender must be fully PCI Compliant. Should the client indicate that they hold this certification, Fidel will require a copy of their Attestation of Compliance, this is essentially documented evidence that the customer has completed the applicable questionnaires and scans and that their license is still valid (typically an attestation will last for a period of 12 months).

Upsides:

• You are in full control of your card enrolment phase;
• If you currently hold cards on file you can send this information directly to the endpoint.

Downsides

• PCI Compliance is required.

SDK

This is the more widely used option with the main benefit being that the customer is not required to hold PCI Compliance certification. The SDK will inject a secure iFrame into the clients card linking application (should the customer choose to integrate it first) thus as a result transmit raw card information directly to Fidel without the client being exposed to it.

Upsides:

• Removes the requirement in becoming PCI Compliant;
• Fidel has customisation options whereby you can align the iFrame with the branding of your app.

Downsides

• Enrolment essentially becomes event based, card enrolment can only happen one at a time at which point the card data must be presented by the end-user. Where this can become a blocker is in the case where a client holds card information and/or has a requirement to send the data to an additional receiver. See below section on Vaulting as a possible solution.

Limit of no. of times a card can be enrolled

Is there a limit on the number of times a card can be enrolled?

A single payment card can only be enrolled once within a single program. In addition, Visa has a limitation of 5 active enrollments at the same time. This means that a single Visa card (including virtual cards) can only be enrolled in up to 5 programs simultaneously across Fidel API.

Card lost/stolen

How does Fidel handle lost/stolen cards?

As a client, you need to inform clients if a cardholder has reported a lost/stolen card to you. You can simply delete the card and enroll the new card, once the cardholder has received it from their bank.

Cardholder consent

What is cardholder consent and how can I obtain this?

Fidel’s SDK contains a block of text included here is a checkbox that the cardholder must tick in order to proceed with the enrolment.

Note: If the client is enrolling cards directly through the Create Card endpoint, they must ensure that the consent piece is managed by themselves and that this is obtained from the cardholder before any information is sent to Fidel API.

Brand consent

What is cardholder and merchant consent and how can I collect this?

Cardholders and merchants alike must provide consent in order for their transactions to be tracked by Fidel. In both cases, a client cannot proceed until this criteria has been met.

Merchant consent

On the brand level a client must declare the consent status before they are able to create the locations which are aligned to it.

The client has two options at this stage:

• By invitation. This allows the user to enter the details for their contact at the brand, this will have the effect of sending an email notification to that representative which contains a link that the recipient must click on. (NOT RECOMMENDED!)

• Auto-approve. By far the more widely used option, this allows the client to automatically auto approve their brand with the consent status immediately being set to approved. (RECOMMENDED)

Note: This option should solely be used on the proviso that the client has obtained merchant consent through their own agreement with the brand. Whilst it is the customer’s responsibility to do this, Fidel can and will be audited by the card networks who are within their rights to ask for evidence of this.

Pause Brand

Can I pause a brand?

Due to Fidel’s own merchant onboarding processes, this is not currently possible as a brand can only either be onboarded or off-boarding. As it stands, you can only offboard the merchant and when applicable re-onboard the merchant. Usual merchant onboarding timelines apply.

Offers API webhooks

Which webhooks should I listen to when using the Offers API?

The Offers API utilises certain events which fire each time a transaction qualifies for an offer created in your account. These are as follows:

• transaction.auth.qualified
• transaction.clearing.qualified
• transaction.refund.qualified

As referred to above each event will only fire should the transaction meet an offer criteria.

Given this example: the account contains active offer contains a schedule with a 10% discount off purchases made Monday to Friday. If a transaction tracks on a Saturday then this would fall outside of the pre-determined schedule with no message being sent to you.

An added nuance can come into play where you decide to also listen to the core transaction webhooks which are:

• transaction.auth
• transaction.clearing
• transaction.refund

These events will not listen to offers qualified within the account, therefore will always trigger should an enrolled card purchase at an onboarded location.

You may wish to listen to both sets if, for example, you are running multiple offers for each brand, such as having an always-on offer in tandem with a more defined one.

The key factor here is for the client to build additional logic on their side in terms of recognising when they should reward on a message received from Fidel API.

Offer charges

Will I still be charged for a transaction that has not qualified for an offer that I have created in the platform?

Fidel is charged for each transaction that is sent to us by the card schemes irrespective of whether that transaction has qualified or not. Therefore, the charge will still be applicable to you regardless of what your webhook setup is i.e. if you are only listening to the offers webhooks and don't receive the data to your application.

Offer data in webhook

At what point does ‘offer’ data become available in the refund processing webhook?

The presence of the “offer” data depends on the webhook being used. If the you are referring to the transaction.refund.qualified webhook, this should always include the “offer” object in the refund transaction, as this webhook is triggered by refund transactions done on locations linked to offers. However, if the webhook in question is transaction.refund, this one does not require that the refund is connected to an offer, meaning it may or may not contain the “offer” object, even if the location where the refund was done is connected to an offer. As for the originalTransactionID, it is included in refund notifications when we can identify the original transaction associated with the refund, we cannot guarantee the match of these transactions because most of the cases we do not receive information matching original transactions from the card networks.

Add Marketplace offer to my program

How can I add an offer from the Marketplace to my program?

You must be enabled for Marketplace offers, please connect with your Client Success Manager should you wish to enable Marketplace Offers.

Once enabled, please follow below steps on the Fidel Dashboard: A user should firstly navigate to the Offers menu and click on the Marketplace icon:

You can then select from the listing of any offer you wish to add to your program, after clicking you will be displayed with the following screen:

By selecting “Add to a program”, the offer will be migrated into the clients program this will include brand and location information.

‍Note: Merchant Onboarding will always be conducted regardless of whether the location has been picked from the Marketplace or not. Therefore the usual timelines regarding this process still apply.

Finding MIDs (Merchant IDs)

How can a merchant / provider find the MIDs (online and in-store)

MIDs are issued to merchants who accept card payments from their payment processor/acquire. They are referred to as Merchant Identification Number, Merchant ID, or specifically to AMEX - an SE Number (Service Entity Number). Merchants may be able to find there MIDs:

• By speaking to your payment processor or acquirer - it may be located on your invoice, bank statement or your merchant portal ;
• There may be a sticker affixed on the side of your POS/terminal that may include the MID;
• It may be printed on a receipt from the POS terminal;
• It may be reference on the merchant’s bank statement for deposits from their card facility.
  

Invoicing terms/ Brands payment timelines

What are the invoicing terms and flow for Fidel Marketplace offers? What is the process and timelines on the brands paying Fidel and the Publisher?

Please connect with your Sales representative or your Client Success Manager to share the detailed flow with you.

Billing

Any questions in regards to billing, please connect with your Client Success Manager or Sales representative.