Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework credential on file with cardholder/spitballing #83

Draft
wants to merge 2 commits into
base: cof-c
Choose a base branch
from
Draft

Rework credential on file with cardholder/spitballing #83

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c37e5c2
Rework credential on file with cardholder 2
kse-clearhaus Aug 15, 2019
d882641
Fix grammatical errors suggested by MT.
kse-clearhaus Aug 15, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 31 additions & 15 deletions source/index.html.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -340,6 +340,23 @@ Example response (snippet):

## Credential on file

This indicates that the cardholder's payment information is being stored by the
PSP or merchant.

PSPs and merchants may store the cardholder's payment
credentials to allow a returning cardholder to conveniently pay without
entering the payment credentials again. (Explicit agreement with Clearhaus is
required.)

To store and use these stored payment credentials, the transactions that stores
the credentials must be marked with `credential_on_file[type]=cardholder`. All
transactions in such a series are cardholder-initiated.

Refer to [Subsequent credential on file](#subsequent-credential-on-file) for
details about handling subsequent.

### Subscriptions and merchant-initiated intent

Subscriptions are supported using `credential_on_file[]`. There are 2 types of
subscriptions: `recurring` and `unscheduled` (merchant-initiated) credential on
file (UCOF).
Expand All @@ -355,12 +372,20 @@ ad-hoc.
For subscriptions, the first in series transaction is a cardholder-initiated
transaction (CIT) whereas all subsequent transactions are merchant-initiated.

PSPs and merchants may store the cardholder's payment credentials to allow a
returning cardholder to conveniently pay without entering the payment
credentials again. (Explicit agreement with Clearhaus is required.)
To store payment credentials and use these stored payment credentials,
`credential_on_file[]` must be used. All transactions in such a series are
cardholder-initiated.
### Subsequent credential on file

First in series transactions can also be made using the `applepay` and
`mobilepayonline` payment methods, however, subsequent merchant-initiated
transactions must be made using the `card` payment method using the card
details of the initial (first in series) authorization.

Subsequent authorizations are made by using
`credential_on_file[previous]=<ID>`, where `<ID>` is the `id` of the previous
transaction in the series.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've documented it as the ("full") reference, like /authorizations/:id, and I have a reason for that. (Hint: "abstract transaction".) 🙂

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least I think we need to be a bit more precise than "the previous transaction". Is it the authorization or the capture for the transaction? Also, in my opinion we should mention an age limit, e.g. 13 months.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ct-clearhaus abstract transaction as in?

I agree that we need to be more precise. But we should also be terse.
I'll see what I can do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I guess previous depends on how we accept continued transactions in our API.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Abstract transaction": https://github.com/clearhaus/issues-pci/issues/1071#issuecomment-517264132


For `recurring` and `unscheduled`, where subsequent transactions are
merchant-initiated, neither CSC nor 3-D Secure values (see [3-D
Secure](#3-d-secure)) would be included.

### Example

Expand Down Expand Up @@ -402,10 +427,6 @@ Example response (snippet):

This should be followed by a capture except when the amount is `0`.

Subsequent authorizations are made by using `credential_on_file[previous]` which
points to the previous authorization in the series; for `recurring` and
`unscheduled`, where subsequent transactions are merchant-initiated, neither CSC
nor 3-D Secure values (see [3-D Secure](#3-d-secure)) would be included.

````shell
curl -X POST \
Expand Down Expand Up @@ -434,11 +455,6 @@ Example response (snippet):
}
````

First in series transactions can also be made using the `applepay` and
`mobilepayonline` payment methods; however, subsequent merchant-initiated
transactions must be made using the `card` payment method using the card
details of the initial recurring authorization.


## 3-D Secure

Expand Down