Create a Recurring PayIn Registration (Card)
Body parameters
The unique identifier of the user at the source of the transaction.
The unique identifier of the Card object, obtained during the card registration process.
Default value: The unique identifier of the owner of the credited wallet.
The unique identifier of the user whose wallet is credited.
The unique identifier of the credited wallet.
The amount of the first recurring pay-in.
This value can be different from the NextTransactionDebitedFunds
The fees of the first recurring pay-in.
This amount can be different from the NextTransactionDebitedFunds
.
Default value: FirstName, LastName, and Address information of the Shipping object if any, otherwise the user (author).
Information about the end user billing address. If left empty, the default values will be automatically taken into account.
Default value: FirstName, LastName, and Address information of the Billing object, if supplied, otherwise of the user (author).
Information about the end user’s shipping address. If left empty, the default values will be automatically taken into account.
The date and time at which the recurring pay-ins will end. This value has no impact on the recurring registration Status
.
Caution: If the EndDate
is left unspecified, please bear in mind that one could be defined by default and be displayed to your end users (not taken into account in the payment recurrence).
Allowed values: Daily
, Weekly
, TwiceAMonth
, Monthly
, Bimonthly
, Quarterly
, Semiannual
, Annual
, Biannual
The frequency at which the recurring pay-ins will occur:
Daily
– 1 transaction per day.Weekly
– 1 transaction every 7 days.TwiceAMonth
– 2 transactions per month.Monthly
– 1 transaction per month.Bimonthly
– 1 transaction every 2 months.Quarterly
– 1 transaction every 3 months.Semiannual
– 1 transaction every 6 months.Annual
– 1 transaction per year.Biannual
– 1 transaction every 2 years.
Whether or not the recurring pay-ins’ debited amounts remain the same for all the pay-ins linked to the recurring registration object.
Whether or not the recurring pay-ins are being made to split a payment in several installments.
The number of initial consecutive pay-ins where there will be no debited funds nor fees.
This value cannot exceed the CycleNumber
value (for recurring objects with an EndDate
, FixedNextAmount
, and Frequency
).
Note: When creating a recurring pay-in (MIT) for a pay-in subject to a free cycle, the DebitedFunds
and Fees
parameters should be ignored. Otherwise, the pay-in will fail with the corresponding error returned.
Whether or not to attempt the first recurring pay-in as a merchant-initiated transaction (MIT).
Caution: Migration is no longer supported. You can only use objects with Migration
set to false
. When Mangopay decommissions this parameter (date communicated by email), the false
value will be forced on all objects, including existing ones. Before decommissioning, you need to re-create the object; after decommissioning, you can re-authenticate the same object.
The need to re-authenticate may be indicated by the Status
changing to AUTHENTICATION_NEEDED
or by errors on the pay-in request, for example: non-existent card account (008008), soft decline (101305), expired card (101105), or stolen card (008003).
The amount of the subsequent recurring pay-ins.
If this field is empty and either FixedNextAmount
or FractionedPayment
are true
, the subsequent amount will be the same as FirstTransactionDebitedFunds
amount.
The fees of the subsequent recurring pay-ins.
The unique reference generated for the profiling session, used by the fraud prevention solution to produce recommendations for the transaction using the profiling data.
Note: Parameter not returned by the API. Profiling feature available on request – contact Mangopay via the Dashboard for more information.
Responses
Was this page helpful?