Use cases

Use cases

The card schemes' COF framework defines the fair use of stored card data by guiding you through a set of questions:

• Once your customers have processed the initial transaction, who is initiating the subsequent payments?
  Your customer her-/himself (for a CIT)?
  You on her/his behalf (for a MIT)?
• Do you need to use a token or the payment.id for subsequent payments?
• Do you need the explicit consent from your customers to reuse card data (to follow standing instructions, i.e. for a recurring service or an instalment plan)? Or is it justified not take this into account (which applies to certain industry practices, i.e. to charge additional fees for certain products/services)?
• Will future standing instructions happen on a recurring / (un)scheduled basis?
• Does your customer have to pass a 3-D Secure check for the individual payments?
• Will subsequent payments have fixed or variable amounts?

But how can you honour this framework and implement it in your business logic? To do so, you need to identify the individual use case(s) that apply to your service.

Use this flowchart to identify how to request both the initial and the subsequent transactions. Depending on the outcome, you need to

• Include certain properties in your request – we provide JSONs accordingly.
• Target a specific endpoint of our PAYONE E-Payment API.

Depending on your where you end up, you will identify a specific use case. Each use case comes with a JSON and the API endpoint for both the initial payment (to start the payment series) and the subsequent payment (to continue the payment series):

Overview

Use case	Merchant actions	JSON/API endpoint
Your customers can actively initiate a transaction (a CIT) in your webshop for future payments any time they want to.	Initial payment: Create and store the token.  Roll out 3-D Secure, allowing you to skip this step for subsequent payments. Subsequent payments: Use the token. Choose whether to roll out/skip 3-D Secure.	Initial payment: Sample B Subsequent payments: Sample C
Your business requires you to initiate future payments (MITs) on behalf of your customers without their explicit approval as an established industry practice.	Initial payment: Do not store the token but the payment.id. Roll out 3-D Secure to ensure the fair use of the payment.id without 3-D Secure for future payments. Subsequent payments: Use the payment.id. Our platform skips 3-D Secure automatically as your customers are not present to make the payment.	Initial payment: Sample X Subsequent payments: Sample G / H / I / J
Your customers buy a recurring service for an extended period. They authorise you to charge fixed amounts (MITs) on a recurring basis in fixed intervals as a standing instruction.	Initial payment: Do not store the token but the payment.id. Roll out 3-D Secure to ensure the fair use of the payment.id without 3-D Secure for future payments. Subsequent payments: Use the payment.id. Our platform skips 3-D Secure automatically as your customers are not present to make the payment.	Initial payment: Sample A Subsequent payments: Sample E
Your customers buy a recurring service for an extended period. They authorise you to charge amounts for future payments (MITs), but both the amount and the intervals may vary between the payments as a standing instruction.	Initial payment: Do not store the token but the payment.id. Roll out 3-D Secure to ensure the fair use of the payment.id without 3-D Secure for future payments. Subsequent payments: Use the payment.id. Our platform skips 3-D Secure automatically as your customers are not present to make the payment.	Initial payment: Sample B Subsequent payments: Sample F
Your customers buy a good / service. They authorise you to charge the amount over a certain period of time via instalments (MITs). Both the amount and intervals are fixed as a standing instruction.	Initial payment: Do not store the token but the payment.id. Roll out 3-D Secure to ensure the fair use of the payment.id without 3-D Secure for future payments. Subsequent payments: Use the payment.id. Our platform skips 3-D Secure automatically as your customers are not present to make the payment.	Initial payment: Sample B Subsequent payments: Sample D