Card-on-File

Recurring Payment

You can perform recurring payments by just adding one additional parameter, standingInstruction, to the payment request.

A recurring workflow consists of two phases:

  1. The initial payment request
  2. Subsequent payment requests

Sending the initial Payment

During the initial payment, marked by the parameter standingInstruction.mode with the value INITIAL, standingInstruction.type with the value UNSCHEDULED and standingInstruction.source with the value CIT, the customer is present. Therefore this initial request should contain additional parameters that authenticate the customer like card.cvv for card payments, and also additional checks like 3D secure can be executed.

In PayUnity.Flex you get this behaviour out of the box, so all you have to do is to follow the PayUnity.Flex Integration guide and add to the /checkouts request in step 1 this parameter:

Use Case 1 : 
  • standingInstruction.mode=INITIAL 
    •  
  • standingInstruction.type=UNSCHEDULED 
    •  
  • standingInstruction.source=CIT
    • Use Case 2 : 
  • standingInstruction.mode=INITIAL 
    •  
  • standingInstruction.type=RECURRING
    •  
  • standingInstruction.source=CIT
    • Follow the section Card On File for possible standingInstruction parameters.

    Using the server-to-server integration, you either have the option to append the parameter standingInstruction to the initial /payments request that also stores the token like in this example:

    For some cases you might want to use an alternative approach: If the shopper just registered his data without sending a payment at the same time you would have sent his payment directly to the /registrations endpoint as described here. In the same way as described above, the standingInstruction.mode=INITIAL, standingInstruction.type=UNSCHEDULED and standingInstruction.source=CIT parameters can be added to the request to indicate that this is the first in a series of recurring payments.

    You can find more details on the server-to-server option using either /payments or /registrations in the the tokenisation tutorial.

    Sending a repeated payment

    Any payment request following the initial one has to have the parameter standingInstruction.mode with the value REPEATED, standingInstruction.type with the value UNSCHEDULED , standingInstruction.source with the value MIT and standingInstruction.initialTransactionId with a value as ID received in the response of the initial CIT transaction. This flag not only indicates that the request is part of a series of payments on this account, but also tells the payment system that no user is present and therefore parameters like card.cvv or the 3D authentication shouldn't be present. This fact in combination with the stored payment data of the registration greatly reduces the number of parameters of such a request:

    Use Case 1 : 
  • standingInstruction.mode=REPEATED
    •  
  • standingInstruction.type=UNSCHEDULED 
    •  
  • standingInstruction.source=MIT
    • Use Case 2 : 
  • standingInstruction.mode=REPEATED
    •  
  • standingInstruction.type=RECURRING
    •   
  • standingInstruction.initialTransactionId=123456780 Note: This value is received in original CIT transaction response
    •  
  • standingInstruction.source=MIT
    • Follow the section Card On File for possible standingInstruction parameters.