SCT transfer and Virtual IBAN Copy section link Copied!
SCT Transfer Copy section link Copied!
Processing workflow Copy section link Copied!
Payment characteristics Copy section link Copied!
Payment method
SCT
SCT inst
PISP SCT
PISP SCT inst
Countries
SEPA Europe zone
SEPA Europe zone
SEPA Europe zone
SEPA Europe zone
Payment execution
Shopper's initiative
Shopper's initiative
Marketplace initiative
Marketplace initiative
Currency
EUR
EUR
EUR
EUR
Funds collection
2 to 3 working days after shopper's request to their bank
Moments after shopper's request to their bank
2 to 3 working days
Moments after shopper's request to their bank
Payment dispute
yes
yes
yes
yes
Refunds
yes
yes
yes
yes
Partial refunds
yes
yes
yes
yes
Partial captures
No
No
No
No
Recurring payments
yes
yes
No
No
Virtual IBAN Copy section link Copied!
Definition and description Copy section link Copied!
IBAN stands for International Bank Account Number. It is based on ISO 13616 standard and allows an homogenous and unique identifier for bank account in all supported countries. Its structure is as follows:
Country code
Control Key
IID: Payment Institution Identifier
BAN: Bank Account Number
2 letters
2 figures
3 to 12 positions
8 to 20 positions
For instance in France and more especially for CAPS-EP (CAPS Etablissement de Paiement) the following example applies:
Bank code
Counter code
Account number
Control Key
FR76
17378
CCCCC
AAAAAAAAAAA
KK
Basically, when we refer to virtual IBAN, it follows the rules described for generic IBAN, but the account is not related to an individual or a business.
This identifier is virtual and generated on demand by AgoraPay. Hence the payment institution (here CAPS-EP) is capable to collect the funds transferred and use this identifier for an operation related to the customer’s basket on the marketplace.
Reconciliation and dispatching the funds to the different merchants payment account are easier thanks to the virtual IBAN. This method makes the reconciliations at the AgoraPay level more reliable and faster, and therefore speeds up the reporting of information to the MKP.
Usecase Copy section link Copied!
In SCT, a new invoice is generated for the same customer, the Virtual IBAN may be identical to the previous one, or different. Both cases are possible and it is the marketplace which decides which one to use.
For a SCT payment AgoraPay generates a virtual IBAN and provides it to the MKP to display it to the customer. By default for each new order a new virtual IBAN is generated. However, the MKP has the possibility to ask AgoraPay to use a virtual IBAN generated during a previous order.
To do so, some conditions must be respected:
- Display to the customer this virtual IBAN (which will have been previously stored by the MKP during its generation at the 1st order)
- Have in the payment request the same orderReference and Payer reference used during the generation of this virtual IBAN at the previous order.
If these conditions are not respected and the MKP pushes the virtual IBAN, the payment request will be rejected.
If the customer makes a mistake and do two transfers, AgoraPay notifies the marketplace of the anormal funds received. Either AgoraPay stores the funds or the marketplace can ask for a refund.
The customer can also make an 'R' message (recall) through his bank, then it is the marketplace's responsibility to accept or refuse the refund.
In the event of an additional transfer to this same IBAN from the buyer, the payment will complement the already existing transactionId, and the amount collected will be incremented.
In the event of partial collection, the adjusted transaction can be readjusted downwards to be considered collected.
Example: If we expect 100€ for a transaction and we only receive 40€, it will remain in partial status and the marketplace can choose to adjust the payment (API AdjustPayment) specifying that the sum expected is 40€. Then, the status will be changed to: Cashed.