Overview
User management
- Users
- User regulatory status
- User e-money
User verification
- User data format
- KYC documents
- UBO declarations
Wallets
- User wallets
- Client wallets
Cards
- Card registrations
- Cards
- Metadata
- Card validations
Card pay-ins
- Direct card pay-ins
- Recurring card pay-ins
- Preauthorizations
- Deposit preauthorizations
- Web card pay-ins
Banking pay-ins
- Bank wires
- Virtual IBAN
- Direct debits
- Web direct debits
APM pay-ins
- Apple Pay
- Bancontact
- BLIK
- Giropay
- Google Pay
- iDEAL
- Klarna
- MB WAY
- Multibanco
- Payconiq
- PayPal
- Satispay
- Swish
- TWINT
Transfers
- Transfers
Refunds
- Refunds
Disputes
Payouts
- Bank accounts
- Payouts
FX conversions
- Conversion rates
- Quotes
- Conversions
Transactions
- Transactions
Helpers
- API responses
- Country authorizations
- Webhooks
- Events
- Reports
Platform account
- Client
- Dashboard permissions
List Disputes pending settlement
This call lists all the disputes for which you need to make a settlement transfer.
Responses
The list of disputes automatically created by Mangopay.
The dispute automatically created by Mangopay.
The unique identifier of the initial pay-in being disputed.
Returned values: PAYIN
The type of the initial transaction being disputed.
Returned values: REGULAR
, REPUDIATION
, REFUND
, SETTLEMENT
The nature of the initial transaction being refunded, providing more information about the context in which the transaction occurred:
- REGULAR – Relative to most of the transactions (pay-ins, payouts, and transfers) in a usual workflow.
- REPUDIATION – Automatic withdrawal of funds from the platform’s repudiation wallet as part of the dispute process (when the user requested a chargeback).
- REFUND – Reimbursement of a transaction to the user (pay-in refund), to a wallet (transfer refund), or of a payout (payout refund, only initiated by Mangopay).
- SETTLEMENT – Transfer made to the repudiation wallet by the platform to settle the credit from a repudiation following a lost dispute.
Returned values: CONTESTABLE
, NOT_CONTESTABLE
, RETRIEVAL
The type of dispute:
CONTESTABLE
– Dispute for which the chargeback can be contested by providing proof (i.e., Dispute Documents) justifying the original transaction.NOT_CONTESTABLE
– Dispute that is automatically closed after its creation, without any action possible for the platform.RETRIEVAL
– Dispute that is actually a chargeback warning issued by the bank. The platform is required to provide documents, but no funds will be taken from the Repudiation Wallet.
The date and time until which the platform can contest the dispute (i.e., the Status
is set to SUBMITTED
). This date is defined by the issuing bank of the initial transaction and may usually vary between 7 to 18 days. Once the deadline passes, the dispute Status
is automatically set to CLOSED
.
Information about the disputed funds.
Note: This amount can be lower than the initial transaction amount.
Returned values: The three-letter ISO 4217 code (EUR, GBP, etc.) of a supported currency (depends on feature, contract, and activation settings).
The currency of the funds.
An amount of money in the smallest sub-division of the currency (e.g., EUR 12.60 would be represented as 1260
whereas JPY 12 would be represented as just 12
).
Information about the contested funds, in other words, the amount that you wish to contest.
Note: This amount can be lower than the disputed funds amount.
Returned values: The three-letter ISO 4217 code (EUR, GBP, etc.) of a supported currency (depends on feature, contract, and activation settings).
The currency of the funds.
An amount of money in the smallest sub-division of the currency (e.g., EUR 12.60 would be represented as 1260
whereas JPY 12 would be represented as just 12
).
Returned values: CREATED
, PENDING_CLIENT_ACTION
, SUBMITTED
, PENDING_BANK_ACTION
, REOPENED_PENDING_CLIENT_ACTION
, CLOSED
The status of the dispute:
CREATED
– The dispute is created.PENDING_CLIENT_ACTION
– The dispute was not closed automatically upon its creation, it now requires some actions from the platform (either submission after providing the relevant proofs or closing).SUBMITTED
– The dispute is submitted by the platform for the Mangopay team to review the documents.PENDING_BANK_ACTION
– Mangopay accepted the documents and passed them on to the bank for them to review the dispute contestation. They will either reject or accept the contestation, or require further documents.REOPENED_PENDING_CLIENT_ACTION
– Mangopay didn’t accept the documents and requires more information or documents before sending the documents to the bank.CLOSED
– The dispute is closed.
Additional information about the dispute Status
communicated by Mangopay teams.
Returned values: LOST
, WON
, VOID
The result of the dispute for the platform, which can be:
LOST
– The platform lost the dispute and must settle its debt to Mangopay with a Settlement Transfer.WON
– The platform won the dispute, the disputed funds will be credited back to the Repudiation Wallet.VOID
– The dispute has been canceled.
The explanation of the result code.
The unique identifier of the object.
Max. length: 255 characters
Custom data that you can add to this object.
The date and time at which the object was created.
The date and time the dispute was closed (i.e., its Status
is set to CLOSED
).
Note: This value will be null
for any Dispute closed before February 16th, 2023.
The unique identifier of the repudiation.
Was this page helpful?