You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 8, 2024. It is now read-only.
Adds a version header to the private API, to provide a better experience for any partner that uses our reference implementation as their production PayID server.
The PayID-API-Version header needs to be an ISO8601 date string, of the form YYYY-MM-DD. This is what Coinbase, Stripe, and various other companies use to version their hosted API services.
Note that I kept the /v1/ in the path for the private API. I chose to do this as Coinbase, Stripe, etc. do the same thing. We should never need to increment to /v2/ in the path, but it's cheap to leave it there, makes a smaller diff, and gives us a safety valve for the future.
Copy file name to clipboardExpand all lines: aws-deploy.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,7 @@ You can set up a PayID server on AWS (Amazon Web Services).
46
46
13. Load up your desired PayID to the database using the [private PayID API](readme.md). If you use a subdomain rather than a path, then you must set up a DNS record for the subdomain as described in step 3.
47
47
**Note:** You can add PayIDs for each (payId, network, environment) tuple. Use this cURL command to set up a PayID.
48
48
```
49
-
curl --location --request POST 'http://127.0.0.1:8081/v1/users' \
49
+
curl --location --request POST 'http://127.0.0.1:8081/users' \
The returned JSON object is our payment setup details. In this example, the institution is a VASP and has listed any laws that must be complied with in the `complianceRequirements` field of the payment setup details. Specifically, as the originator of the payment we are being asked to comply with the Travel Rule. In order to do that, we'll POST the compliance data to the same URL in order to upgrade our payment setup details object.
37
+
36
38
```
37
39
curl --location --request POST 'http://127.0.0.1:8080/exampleUser/payment-setup-details' \
38
40
--header 'Content-Type: application/json' \
@@ -65,8 +67,8 @@ curl --location --request POST 'http://127.0.0.1:8080/exampleUser/payment-setup-
65
67
}'
66
68
```
67
69
68
-
69
70
Upon submission of this data, the beneficiary should identify that we have fulfilled all compliance requirements and send us an upgraded payment setup details object. This upgraded payment setup details cryptographically correlates our submission of compliance data through the complianceHashes field. Now that we have been informed of all compliance requirements, and fulfilled them, we can submit our transaction on ledger and POST back the payment proof.
71
+
70
72
```
71
73
curl --location --request POST 'http://127.0.0.1:8080/exampleUser/payment-proofs' \
"A PayID-API-Version header must be in the form 'PayID-API-Version: YYYY-MM-DD'.",
32
+
ParseErrorType.InvalidPayIdApiVersionHeader,
33
+
)
34
+
}
35
+
36
+
// Because they are ISO8601 date strings, we can just do a string comparison
37
+
if(payIdApiVersionHeader<privateApiVersions[0]){
38
+
thrownewParseError(
39
+
`The PayID-API-Version ${payIdApiVersionHeader} is not supported, please try upgrading your request to at least 'PayID-API-Version: ${privateApiVersions[0]}'`,
0 commit comments