CardOperations

The CardOperations section allows you to manage all aspects of collecting, validating, authenticating, storing and charging the card details from the card owner.
With the CardOperations, you can design your own payment flow based on your needs and specifications. You can perform the CardOperations either in our default form or you can design your own form(s) to perform the card operations there. Additionally, if you would like, you can store your forms in Orchestra and embed them into your website (this can help take you out of PCI compliance scope).

📘

Custom Forms

Adding custom forms can be achieved either from our portal or via our API.

We assume that your web application will submit all CardOperations from the client. However, since the data sent from the client - either to our API or back to your server, can be compromise, we have designed an authentication process that will serve to both pass data between your server and our API - via the client, and to authenticate the request itself.

For the first step, regardless of which card operations you need to perform, you will need to start the Card Operations session by using [POST] /CardOperations. This method will allow your server to specify to the API which operations are permitted within this CardOperations session and provide all parameters that the client should not be able to manipulate (for example, value of the transaction).
The response to this method would be a JWS authentication token which will be used in all subsequent requests within the CardOperations process.

📘

Mixed Authentication Mechanisms

The methods in the CardOperations utilize two forms of authentication.

  • The [POST] /CardOperations method, to start a CardOperations session, uses your API key as authentication. The result of which is an authentication code.
  • The other methods under CardOperations all use bearer token authentication (the bearer token is the authentication code returned in the response to the initial [POST] /CardOperations method.

Once you received the AuthToken for this CardOperations session, you can then submit any of the CardOperations methods to perform any of the following actions on the card:

In each of these methods, you will need to provide the specific details necessary to complete this operation (keep in mind that some, and perhaps even all) of the data necessary for this operation has already been provided as part of the process of creating the session.
The response of each of these methods will include both the specific result of the operation performed and an updated JWS AuthToken which should be used as the bearer authentication token of the next request.

You can perform these actions in any order that suits your needs and your workflow, and you can run them as many times as needed. You can design either the client app or the server app (we would recommend the server app) to define the conditions and the logic of when and following what result to proceed to the next step (for example, you might not want to process a charge on a card that failed 3D Secure authentication or you would not want to store a card that the charge was rejected due to invalid card).

In addition to the CardOperations methods, we also offer a method to validate the AuthToken which allows you to confirm the responses your server receives from the client.