> ## Documentation Index
> Fetch the complete documentation index at: https://www.marqeta.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Working with Regulation E
> Manage provisional credit for programs enabled for Regulation E.
[Regulation E](https://www.federalreserve.gov/supervisionreg/regecg.htm), the United States regulation implementing the Electronic Fund Transfer Act, provides a framework for protecting customers who use electronic methods to transfer money, as well as guidelines for electronic debit card issuers throughout the dispute investigation process.
Regulation E allows up to 45 calendar days (90 days in certain cases) to resolve these disputes, but during that time you must issue a provisional credit for the disputed amount. The provisional credit must be provided within 10 business days after the customer made first contact. If a dispute is not resolved within the required 45-day (90-day in certain cases) time frame, Marqeta makes the provisional credit permanent without confirmation.
**Note**\
The endpoints on this page require Regulation E activation steps before they can be used. To learn more about these endpoints and activating them for your program, contact your Marqeta representative.
Provisional credit overview
When you create a Regulation E dispute case using the `/cases` endpoint:
* Use the `cardholder_contact_date` field to add the date of first cardholder contact. When you create the case, the 45-day clock begins. Marqeta provides this milestone due date in the response payload.
* Grant the customer provisional credit using the `GRANT_PROVISIONAL_CREDIT` action in the actions endpoint, which transfers funds from the program account to the cardholder account. This endpoint can only be called before card network submission.
* If provisional credit is not provided at time of submission to the card network, Marqeta sends you an error response and moves the case to an `OPEN_WITH_ACTION_REQUIRED` state.
* If provisional credit has been provided and other card network requirements are satisfied, you can submit to the card network using the `CHARGEBACK_SUBMIT` dispute transition action.
Managing provisional credit
The following sections describe how to manage provisional credit using the `cases` endpoint if your program is enabled for Regulation E.
Creating the dispute case
If the dispute reason has a supported dispute reason code, a chargeback is created when you create the dispute case. The chargeback token is stored in `dispute_details` and the `regulation_type` field is set to `REG_E`.
A `PC_PENDING` milestone is created with a due date calculated as follows for provisioning credit:
`cardholder_contact_date + days to act`
Monitoring elapsed time
For Regulation E cases, it is your responsibility to provide a provisional credit within 10 business days of the `cardholder_contact_date`. The [Disputes dashboard](/developer-guides/disputes-dashboard/) provides a warning if the 10-business-day timeline for providing provisional credit is expiring. To look up the expiration date for one-off cases, use the `GET /cases/{token}/milestones` endpoint and look for the `next_milestone_due_date` when the milestone is set to `PENDING_PC_GRANTED` for the `PROVISIONAL_CREDIT` subcategory. If provisional was not provided within the regulation time frame, the system will still allow you to grant provisional credit.
Granting provisional credit
To grant provisional credit, use the `POST /cases/{token}/actions` endpoint with `GRANT_PROVISIONAL_CREDIT` as the `action_type`. Provisional credit must be granted before the case enters the `CHARGEBACK_INITIATED` state. The credit can be granted while the dispute case states in any of the following states: `OPEN`, `OPEN_WITH_ACTION_REQUIRED`, or `READY`. This triggers the `ProvisionalCreditGranted` event and sets the `provisional_credit_granted` field in `dispute_details` to `true`.
This triggers the `authorization.clearing.chargeback.provisional.credit` webhook.
Submitting a dispute to the card network
Before you submit a dispute case to the card network, you must grant provisional credit.
To initiate a dispute by submitting it to the card network, create a dispute case transition using the `POST /cases/{token}/transitions` endpoint with a `CHARGEBACK_SUBMIT` action to transition the case to `CHARGEBACK_INITIATED`.
If the provisional credit has not been granted, the case is moved to `OPEN_WITH_ACTION_REQUIRED`.
Submitting a dispute case to the card network triggers the `authorization.clearing.chargeback` and the `chargebacktransition.regulation.initiated` webhooks.
Handling card network rejection
There are three possibilities if the chargeback is rejected by the card network:
* **Cardholder should keep the provisional credit** – You determine that the cardholder should keep the provisional credit. In this scenario you would `CLOSE` the case with writeoff program.
* **Cardholder should not keep the provisional credit** – You determine that the cardholder should not keep the provisional credit. In this scenario, close the dispute case with case lost. If the case has been opened for less than 45 calendar days, this triggers the [Post-network submission – case lost pre 45 days](#_post_network_submission_case_lost_pre_45_days) use case.
* **Cardholder is at fault, but 45 calendar days have passed** – You determine that the cardholder is at fault, but the case has been opened for more than 45 calendar days. In this scenario, you would `CLOSE` the case with writeoff program, given that the credit has already been made permanent.
If a case is rejected by the card network, Marqeta provides you with a reject reason, sends a `regulation.network.rejected` webhook, and moves the case to the `OPEN_WITH_ACTION_REQUIRED` state. You are responsible for evaluating the card network rejection and determining if the dispute should be resubmitted. If you choose to resubmit, Marqeta continues to persist the provisional credit against the customer account.
You are responsible for notifying the cardholder of the final decision.
For a card network rejection use case, see [Post-network submission – card network rejection](/developer-guides/disputes-regulation-e/#_post_network_submission_card_network_rejection).
Pre-network submission cases
In these two cases you may want to withdraw and close before submitting to the card network:
* You create a dispute case and then discover that the disputed transaction has an associated transaction for a refund or credit already in the system.
* After investigating a dispute case rejected by the card network, you determine that the case is lost and want to close the case.
For each of these use cases, see [Pre-network submission – withdraw and close](/developer-guides/disputes-regulation-e/#_pre_network_submission_withdraw_and_close) and [Pre-network submission – close with case lost pre 45 days](/developer-guides/disputes-regulation-e/#_pre_network_submission_close_with_case_lost_pre_45_days).
Case lost
If the case is lost, transition the dispute to `CLOSED` with case lost reason code. This puts the case in the `PENDING_CLOSED` state, which requires you to:
* Notify the cardholder at least five days in advance that the credit will be reversed.
* Trigger an event with the date of notification.
* Wait five days for the funds to be reverted and the case to be closed by the system.
* Indicate to Marqeta that you notified the cardholder and when you notified them. Marqeta will reverse the credit eight days from when the case was lost.
The following sections provide details for a case lost scenario. For case lost use cases, see [Post-network submission – case lost pre 45 days](/developer-guides/disputes-regulation-e/#_post_network_submission_case_lost_pre_45_days) and [Post-network submission – case lost post 45 days](/developer-guides/disputes-regulation-e/#_post_network_submission_case_lost_post_45_days).
Managing elapsed time
If the current date is more than 45 days after the `cardholder_contact_date`, the provisional credit is made permanent. For details, see [Permanent credit](#_granting_permanent_credit). If the current date is less than 45 days after the `cardholder_contact_date`, and the case is lost, the `case_lost` state is recorded and a `Case Lost CC Pending` event is generated.
To determine the due date for the `PC_PERM`, use the `GET /cases/{case-token}/milestones` endpoint and refer to the `next_milestone_due_date` when the current milestone is set to `PC_GRANTED`.
When the `CaseLostNotifyCardholder` event is triggered, a `regulation.case.lost.action.required` webhook is sent with the expectation that you will notify the cardholder of the reversal of funds at least five days in advance.
The milestone is updated to `PENDING_PC_REVERSAL` with the next `milestone_due_date` set to eight days from the time the case was moved to the `PENDING_CLOSED` state.
A new `CASE_LOST_PENDING_COMMS` milestone is also created with a `next_milestone_due_date` set to three days from the time the case was moved to `PENDING_CLOSED`.
Notifying the cardholder
Once you notify the cardholder, you must trigger a `CaseLostNotificationSent` event and specify a date when you notified the cardholder through the `event_date` field. This updates the `next_milestone_due_date` for the `PENDING_PC_REVERSAL` milestone.
If you do not send the `CaseLostNotificationSent` event, a `CaseLostNotifyCardHolderExpired` event will move the milestone from `CASE_LOST_PENDING_COMMS` to `CASE_LOST_COMMS_EXPIRED`. In this scenario, you will no longer be able to change the `next_milestone_due_date` for the `PENDING_PC_REVERSAL`. Failing to send the `CaseLostNotificationSent` event will result in the cardholder’s account being debited without any prior notice. It might also result in the cardholder’s account being debited on a date different than what was previously communicated to the cardholder.
To see when the reversal of credit is due, use the `GET /cases/{case-token}/milestones` endpoint and refer to the `next_milestone_due_date` for the `PENDING_PC_REVERSAL` milestone.
Case won
If more than 45 days have passed from the `cardholder_contact_date`, the provisional credit is made permanent. For details on permanent credit, see [Granting permanent credit](#_granting_permanent_credit). If `case_won_date` is less than 45 days after the cardholder contact date, the `case_won` state is recorded and a `provisional credit perm` event is generated. It is your responsibility to inform Marqeta of the date of the `provisional credit perm` confirmation and that the `Case Won` confirmation were sent to the cardholder.
For a case won use case, see [Post-network submission – case won](/developer-guides/disputes-regulation-e/#_post_network_submission_case_won).
Granting permanent credit
If no case decision is recorded within 45 days of the cardholder contact date, a webhook is generated indicating that provisional credit to the cardholder should be made permanent. It is your responsibility to inform Marqeta of the date that the `provisional credit perm` and that the `Case Won` or `Case Lost` confirmation was sent to the cardholder. The case continues investigation with the card network, but any subsequent updates should not impact the cardholder. All ledger-impacting activities after this event should impact the program funding source or Marqeta funding.
Program funding source impact
Provisional credit is taken from the program funding source. When a case is lost or has progressed beyond the 45-day time limit, funds are recouped from the program funding source. After the provisional credit is issued, all ledger impact is on program funding source and the card network account during the dispute lifecycle.
Reason Codes Supported for Reg E Configuration
The following dispute reason codes are supported by Marqeta and are most commonly associated with Reg E.
* `EMV_LIABILITY_SHIFT_COUNTERFEIT_FRAUD` (Visa only)
* `EMV_LIABILITY_SHIFT_NON_COUNTERFEIT_FRAUD` (Visa only)
* `NOT_AUTHORIZED_CARD_PRESENT`
* `NOT_AUTHORIZED_CARD_ABSENT`
* `LATE_PRESENTMENT`
* `INCORRECT_TRANSACTION_CODE`
* `INCORRECT_CURRENCY`
* `INCORRECT_ACCOUNT_NUMBER` (Visa only)
* `INCORRECT_TRANSACTION_AMOUNT` (Visa only)
* `CANCELLED_RECURRING_TRANSACTION`
* `NON_RECEIPT_OF_CASH_OR_LOAD_TRANSACTION_VALUE_AT_ATM`
* `WARNING_BULLETIN_FILE`
* `INCORRECT_TRANSACTION_AMOUNT_OR_ACCOUNT_NUMBER`
* `POINT_OF_INTERACTION_ERRORS`
* `FRAUD_TRANSACTION`
* `QUESTIONABLE_MERCHANT_ACTIVITY`
* `TRANSACTION_NOT_RECOGNIZED`
* `CHIP_LIABILITY_SHIFT`
* `CHIP_PIN_LIABILITY_SHIFT_LOST_STOLEN`
* `CHIP_READ_POS_LATE_PRESENTMENT`
* `DUPLICATE_PROCESSING_OR_PAID_BY_OTHER_MEANS`
Use cases
The following are common scenarios when managing Regulation E dispute cases:
* [Pre-network submission – withdraw and close](#_pre_network_submission_withdraw_and_close)
* [Pre-network submission – close with case lost pre 45 days](#_pre_network_submission_close_with_case_lost_pre_45_days)
* [Post-network submission – card network rejection](#_post_network_submission_card_network_rejection)
* [Post-network submission – case lost pre 45 days](#_post_network_submission_case_lost_pre_45_days)
* [Post-network submission – case lost post 45 days](#_post_network_submission_case_lost_post_45_days)
* [Post-network submission – case won](#_post_network_submission_case_won)
The following sections describe the steps required and responses for each of the use cases. Boldface steps are those that are your responsibility to perform.
Pre-network submission – withdraw and close
In this scenario, a customer creates a dispute case and the disputed transaction has an associated transaction for a refund or credit already in the system. If the refund or credit is for the full amount, you should not grant provisional credit, but instead close the case with `WITHDRAW_AND_CLOSE`.
**Create a dispute case.**\
In the response the `associated_transaction_selection_required` field is set to `true`.
**Get a list of all associated transaction** using the `GET /cases/{case-token}/associated_transactions` endpoint.
**Indicate which transactions are related** if you determine that one of the transactions is already a refund or credit made towards the cardholder using the `POST /cases/{case-token}/associated_transactions` endpoint.
**If one of the associated transaction is related, close the case** using the `POST /cases/{case-token}/transitions` endpoint with the `action` set to `WITHDRAW_AND_CLOSE` and the reason code set to `40`.
Pre-network submission – close with case lost pre 45 days
In this scenario, you submit a case to the card network, but the card network rejects the submission. After further investigation, you determine that the case is lost and close the case. The following steps show the sequence in this scenario:
**Create a dispute case.**
**Grant a provisional credit** using the `POST /cases/{case-token}/actions` endpoint with `type` set to `WITHDRAW_AND_CLOSE`.
**Transition the case to `READY`** using the `POST /cases/{case-token}/transitions` with the `action` set to `REVIEW` and reason code to `05`.
When you attempt to transition the case to `CHARGEBACK_INITIATED` using the `POST /cases/{case-token}/transitions` with the action set to `CHARGEBACK_SUBMIT` and reason code to `51`, the card network returns an error and the case is moved to `OPEN_WITH_ACTION_REQUIRED`. The response provides a reason for the failure in the `failure_reason` field.
**If there is an error, determine if:**
* The failure reason is valid and that the cardholder is at fault.
* The number of days to act from `cardholder_contact_date` is less than 45 days.
**Transition the case to `CLOSED`** using the\` POST /cases/\{case-token}/transitions\` with the `action` set to `CLOSE` and reason code to `42`. The dispute case moves to `PENDING_CLOSED` and the `regulation.case.lost.action.required` webhook is sent.
**Notify the cardholder** that the reversal will happen in five business days.
Trigger an event through the `POST /cases/{case-token}/events` using name `CaseLostNotificationSent` and provide the date when the cardholder was notified in the `event_date` field.
After five business days from the `event_date`, the funds are reversed.
**Transition the case to `CLOSED`** using the `POST /cases/{case-token}/transitions` endpoint with the action set to `CLOSE` and the reason code set to `42`.
Post-network submission – card network rejection
In this scenario, you submit a case to the card network, but the card network rejects the submission. After further investigation, you determine that there is no chargeback, but you would like to return the money to the cardholder. The following shows the sequence of steps:
**Note**\
Another scenario could be that the cardholder is at fault, but the days to act from `cardholder_contact_date` has exceeded 45 days.
**Create a dispute case.**
**Grant a provisional credit** using the `POST /cases/{case-token}/actions` with the type set to `WITHDRAW_AND_CLOSE`.
**Transition the case to `READY`** using the `POST /cases/{case-token}/transitions` with the action set to `REVIEW` and reason code to `05`.
**Attempt to transition the case to `CHARGEBACK_INITIATED`** using the `POST /cases/{case-token}/transitions` with the action set to `CHARGEBACK_SUBMIT` and reason code to `51`.
The card network returns an error and the case is moved to `OPEN_WITH_ACTION_REQUIRED`. The response includes a reason for the failure in the `failure_reason` field.
**Determine the failure reason and whether the cardholder is at fault**. In this case, you determine the failure reason is valid and that the cardholder is at fault, but you will still refund the cardholder.
**Transition the case to `CLOSED`** using the `POST /cases/{case-token}/transitions` with the action set to `CLOSE` and the reason code to `45`.
Post-network submission – case lost pre 45 days
This scenario outlines for going to `REPRESENTMENT`, but this can also apply if the case goes to `PRE_ARBITRATION` or `ARBITRATION`.
**Create a dispute case.**
**Grant a provisional credit** using the `POST /cases/{case-token}/actions` with the type set to `WITHDRAW_AND_CLOSE`.
**Transition the case to `READY`** using the `POST /cases/{case-token}/transitions` with the action set to `REVIEW` and reason code to `05`.
**Transition the case to `CHARGEBACK_INITIATED`** using the `POST /cases/{case-token}/transitions` endpoint with the action set to `CHARGEBACK_SUBMIT` and reason code to `51`. This sets the `dispute_state` to `INITIATED`.
The card network and transitions the dispute case to `REPRESENTMENT`.
Determine whether you agree with the card network.
The number of days to act from `cardholder_contact_date` is less than 45.
Create a card network transition using the `POST /cases/{case-token}/disputetransitions` with the action set to `ACCEPT_AND_CLOSE`.
The card network dispute state is set to `CASE_LOST` and the case state to `PENDING_CLOSED`.
The `regulation.case.lost.action.required` webhook is sent.
**Notify cardholder that the reversal will happen** in five business days.
**Trigger an event** using the `POST /cases/{case-token}/events` with name `CaseLostNotificationSent` and provide the date when the cardholder was notified in the `event_date` field.
After five business days from the `event_date`, the funds are reversed.
**Transition the case to `CLOSED`** through the `POST /cases/{case-token}/transitions` with the action set to `CLOSE` and reason code to `42`.
Post-network submission – case lost post 45 days
In this scenario, the case is lost after the 45 days have passed. In this scenario, the dispute case goes to `REPRESENTMENT`, but this can also apply if the dispute case goes to `PRE_ARBITRATION` or `ARBITRATION`.
**Create a dispute case.**
**Grant a provisional credit** using the `POST /cases/{case-token}/actions` with the type set to `WITHDRAW_AND_CLOSE`.
**Transition the case to `READY`** using the `POST /cases/{case-token}/transitions` with the action set to `REVIEW` and the reason code set to `05`.
**Transition the case to `CHARGEBACK_INITIATED`** using the `POST /cases/{case-token}/transitions` endpoint with the action set to `CHARGEBACK_SUBMIT` and the reason code set to `51`. This sets the `dispute_state` to `INITIATED`.
The card network transitions the card network dispute state to `REPRESENTMENT`.
In this scenario, the days to act from `cardholder_contact_date` has passed beyond 45 days.
**Transition the card network dispute state** using the `POST /cases/{case-token}/disputetransitions` endpoint with action set to `ACCEPT_AND_CLOSE`, `write_off` set to `true`, and `write_off_actor` set to `PROGRAM`.
The dispute state is set to `WRITE_OFF_PROGRAM` and the case state to `CLOSED`.
Post-network submission – case won
In this scenario, a post-network submission is set to case won.
**Create a dispute case.**
**Grant a provisional credit** using the `POST /cases/{case-token}/actions` endpoint with `type` set to `WITHDRAW_AND_CLOSE`.
**Transition the dispute case to `READY`** using the `POST /cases/{case-token}/transitions` endpoint with `action` set to `REVIEW` and reason code to `05`.
**Transition the dispute case to `CHARGEBACK_INITIATED`** using the `POST /cases/{case-token}/transitions` endpoint with `action` set to `CHARGEBACK_SUBMIT` and reason code to `51`. This sets the `dispute_state` to `INITIATED`.
The card network transitions the dispute to `REPRESENTMENT`.
In this scenario, the days to act from `cardholder_contact_date` has passed beyond 45 days.
Send a card network transition using the `POST /cases/{case-token}/disputetransitions` endpoint with `action` set to `RESPOND_WITH_PREARB`.
The card network agrees, and you **determine that the case has been won**.
**Transition the card network dispute state** using the `POST /cases/{case-token}/disputetransitions` with action set to `CLOSE_WITH_CASE_WON`.
The dispute case state is set to `CASE_WON` and the case state to `CLOSED`.
## Related topics
- [Working Within a Case](/docs/developer-guides/disputes-portal-working-within-a-case.md)
- [Disputes Overview](/docs/developer-guides/disputes-landing-page.md)
- [Working with UX Toolkit Web Components](/docs/developer-guides/uxt-web-components.md)
- [Working with UX Toolkit within Native Webviews](/docs/developer-guides/uxt-within-native-webviews.md)
- [Disputes (Mastercard)](/docs/core-api/disputes-mastercard.md)