-
Notifications
You must be signed in to change notification settings - Fork 9
/
Copy pathcarrier-billing.yaml
2090 lines (2040 loc) · 90 KB
/
carrier-billing.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
openapi: 3.0.3
info:
description: |-
Service Enabling Payments against Operator Carrier Billing Systems
# Introduction
The Carrier Billing API provides programmable interface for developers and other users (capabilities consumers) to charge an amount on a mobile line.
It can be easily integrated and allows end-users to buy digital content in an easy & secured way. The API provides management of a payment entity and its associated lifecycle.
# Relevant terms and definitions
- **Carrier Billing**:
An online payment process which allows users to make purchases by charging payments against Telco Operator Billing Systems, accordingly to the user's configuration in the Telco Operator. In a common usage in the industry, the payment is processed on current account balance or charged on next bill generated for this line.
- **Payment**:
The process of paying for a (set of) good(s)/service(s).
- **1-STEP Payment**:
Payment process performed in one phase (i.e. one action), that involves all the Telco Operator Carrier Billing Systems checking and trigger the charging request against Billing Systems.
- **2-STEP Payment**:
Payment process performed in two phases (i.e. two actions). First action deals with payment preparation request to guarantee the reservation of the involved amount. Second action is an explicit confirmation or cancellation of the payment by the user. Any payment not confirmed/cancelled by a given user is discarded after some time in order to avoid inconsistency in the billing systems.
# API Functionality
This API allows to third party clients to request the payment of a (set of) digital good(s)/service(s), as well as to retrieve information about a specific payment or a list of payments.
In the scope of **version v0.3, only one-off payments are covered**. Recurrent payments (a.k.a. payment subscriptions) are not covered so far.
The API provides several endpoints/operations:
- An endpoint to request a 1-STEP Payment, named `createPayment`.
- A set of endpoints to request a 2-STEP Payment:
- One endpoint to setup the payment reservation, named `preparePayment`.
- A couple of endpoints to confirm/cancel such payment reservation, named `confirmPayment` and `cancelPayment` respectively.
- A set of endpoints to retrieve information about a list of payments or a specific payment (identified by its specific `paymentId`), named `retrievePayments` and `retrievePayment` respectively.
- A callback endpoint where API Server can send notifications about a payment procedure, as defined within `createPayment` and `preparePayment` operations, towards the `sink` when provided by API client.
The usage of the API is based on Payment resource, which can be created (in 1-STEP or 2-STEP Payment process), confirmed/cancelled (for 2-STEP Payment process), and queried/retrieved (list of payments or a specific payment).
Before starting to use the API, the developer needs to know about the below specified details:
- **Payment service endpoint**: The URL pointing to the RESTful resource of the payment API. As 1-STEP and 2-STEP processes are managed, 2 separate tags _`One Step Payment`_ and _`Two Step Payment`_ have been defined to explicitly distinguish them in the API specification. A third tag _`Payment`_ is defined for common operations in both processes (query/retrieve list of payments or a specific payment).
- **1-STEP & 2-STEP Payment**:
- **1-STEP Payment**: The request intent is to charge an amount to the mobile line. When the server receives the request, it will check the user account associated with this line and, if nothing prevents it, the amount is charged and will be either bill in next invoice or removed from current line credit/balance.
- **2-STEP Payment**: The first call is to request a payment preparation, which implies an amount reservation. The amount is not charged and the server has to be ready to get a confirmation or a cancellation to perform the payment. Only when the confirmation is done, payment is charged. Depending on business rules of the Telco operator, a `prepared` payment could expire after a defined delay.
- **Notification URL**: Developers may provide a callback URL (`sink` param) on which status change notifications, regarding the payment, can be received from the Telco Operator. This is an optional parameter.
Following diagram shows the API resources operation sequencing:
Follow picture provides information about the payment state engine (state description & transition):
State transitions:
**1-STEP Payment**
If `createPayment` is a **SYNC** process:
- Response contains `paymentId` and paymentStatus=`succeeded`.
- In case of any error scenario `paymentId` is not created.
If `createPayment` is an **ASYNC** process:
- Response contains `paymentId` and paymentStatus=`processing`. After completion:
- When payment is successfully completed then paymentStatus=`succeeded`.
- When payment is not successfully performed then paymentStatus=`denied`.
- In case of any error scenario `paymentId` is not created.
**2-STEP Payment**
FIRST STEP
If `preparePayment` is a **SYNC** process:
- **Case A** - `validationInfo` is NOT provided in response.
- Response contains `paymentId` and paymentStatus=`reserved`.
- **Case B** - `validationInfo` is provided in response.
- Response contains `paymentId` and paymentStatus=`pending_validation`.
- In case of any error scenario `paymentId` is not created.
If `preparePayment` is an **ASYNC** process:
- **Case A** - `validationInfo` is NOT provided in response.
- Response contains `paymentId` and paymentStatus=`processing`. After completion:
- When payment preparation is successfully completed then paymentStatus=`reserved`.
- When payment preparation is not successfully performed then paymentStatus=`denied`.
- **Case B** - `validationInfo` is provided in response.
- Response contains `paymentId` and paymentStatus=`processing`. After completion:
- When payment preparation is successfully completed then paymentStatus=`pending_validation`. [1]
- When payment preparation is not successfully performed then paymentStatus=`denied`.
- In case of any error scenario `paymentId` is not created.
[OPTIONAL] VALIDATE STEP [1]
After `validatePayment`, paymentStatus=`reserved` OR `denied`, depending whether it was successful or not.
SECOND STEP
After `confirmPayment`, paymentStatus=`succeeded` OR `denied`, depending whether it was successful or not.
After `cancelPayment`, paymentStatus=`cancelled`.
# Generic Clarification about optional parameters
Regarding optional parameters, they can be conditionally mandatory for a Telco Operator to implement them based on business scenarios or applicable regulations in a given market.
NOTE: Within a given market, in a multi Telco Operator ecosystem, the set of optional parameters to be implemented MUST be aligned among involved Telco Operators.
# Authorization and authentication
The "Camara Security and Interoperability Profile" provides details on how a client requests an access token. Please refer to Identify and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the Profile.
Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.
It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.
# Further info and support
(FAQs will be added in a later version of the documentation)
version: 0.3.1
title: Carrier Billing
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
externalDocs:
description: Product documentation at Camara
url: https://github.com/camaraproject/CarrierBillingCheckOut
x-camara-commonalities: 0.4.0
servers:
- url: "{apiRoot}/carrier-billing/v0.3"
variables:
apiRoot:
default: http://localhost:9091
description: API root, defined by the service provider
tags:
- name: One Step Payment
description: Operations to manage One Step Payment procedure
- name: Two Step Payment
description: Operations to manage Two Step Payment procedure
- name: Payment
description: Operations to obtain information about payments
paths:
/payments:
post:
security:
- openId:
- carrier-billing:payments:create
tags:
- One Step Payment
summary: Create a new Payment
operationId: createPayment
description: Create a new payment for subsequent charging to an end user. Carrier Billing Server will apply the charging according to business configuration for the end user.
parameters:
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: Amount transaction
content:
application/json:
schema:
$ref: "#/components/schemas/CreatePayment"
required: true
callbacks:
notifications:
"{$request.body#/sink}":
post:
security:
- {}
- notificationsBearerAuth: []
tags:
- Payment Notifications
summary: Carrier Billing payment notifications
operationId: createPaymentNotification
description: |
Important: This endpoint is exposed by the API client, accepting requests in the defined format.
The Carrier Billing server will call this endpoint whenever any carrier billing related event occurs.
parameters:
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: Creates a new carrier billing payment notification
content:
application/cloudevents+json:
schema:
$ref: "#/components/schemas/CloudEvent"
required: true
responses:
"204":
description: Successful notification
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
"400":
$ref: "#/components/responses/Generic400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/Generic403"
"410":
$ref: "#/components/responses/Generic410"
"429":
$ref: "#/components/responses/Generic429"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
responses:
"201":
description: Created
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/PaymentCreated"
"400":
$ref: "#/components/responses/PaymentInvalid400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/PaymentPermissionDenied403"
"409":
$ref: "#/components/responses/Generic409"
"422":
$ref: "#/components/responses/PaymentUnprocessable422"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
get:
security:
- openId:
- carrier-billing:payments:read
tags:
- Payment
summary: Get a list of payments
operationId: retrievePayments
description: |-
Retrieve a list of payments and their details based on some filtering criteria.
Regardless the payment criteria provided, response MUST be always limited to payments performed by the API client (i.e same oAuth credentials) triggering this request.
This is to guarantee no API client can check payments performed by other, therefore avoiding any legal or privacy topic.
When Access Token is issued for a given user phone number, the list of payments returned would be only the ones associated to that user phone number and API client. When Access Token is not associated to a user phone number, therefore only associated to API client the list of payments returned would be all the ones managed by that API client.
Considerations regarding `paymentCreationDate.gte`, `paymentCreationDate.lte`:
- If both included, return payments in that date range
- If no one included, no filtering by date range is applied
- If only settled `paymentCreationDate.gte`, `paymentCreationDate.lte` is considered current date-time
- If only settled `paymentCreationDate.lte`, every payment existing in the Operator billing system until such date is returned
parameters:
- $ref: "#/components/parameters/x-correlator"
- $ref: "#/components/parameters/Page"
- $ref: "#/components/parameters/PerPage"
- $ref: "#/components/parameters/StartPaymentCreationDate"
- $ref: "#/components/parameters/EndPaymentCreationDate"
- $ref: "#/components/parameters/Order"
- $ref: "#/components/parameters/PaymentStatus"
- $ref: "#/components/parameters/MerchantIdentifier"
responses:
"200":
description: OK
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
Content-Last-Key:
$ref: "#/components/headers/Content-Last-Key"
X-Total-Count:
$ref: "#/components/headers/X-Total-Count"
content:
application/json:
schema:
$ref: "#/components/schemas/PaymentArray"
"400":
$ref: "#/components/responses/GetPaymentsInvalid400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/PaymentReadPermissionDenied403"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
/payments/{paymentId}:
get:
security:
- openId:
- carrier-billing:payments:read
tags:
- Payment
summary: Get payment details
operationId: retrievePayment
description: |-
Retrieve payment details for a given payment.
When Access Token is issued for a given user phone number, the payment details would be returned in case the `paymentId` is associated to that user phone number and API client, otherwise `404 NOT_FOUND` will be returned. When Access Token is not associated to a user phone number, the payment details are returned in case the API client managed that payment.
parameters:
- name: paymentId
in: path
description: Payment identifier that was obtained from the create payment operation
required: true
schema:
type: string
- $ref: "#/components/parameters/x-correlator"
responses:
"200":
description: OK
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/Payment"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/PaymentReadPermissionDenied403"
"404":
$ref: "#/components/responses/Generic404"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
/payments/prepare:
post:
security:
- openId:
- carrier-billing:payments:create
tags:
- Two Step Payment
summary: Prepare (reserve) a payment
operationId: preparePayment
description: Prepare a new payment procedure. Carrier Billing Server will apply the charging according to business configuration for the end user.
parameters:
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: Amount transaction
content:
application/json:
schema:
$ref: "#/components/schemas/BodyAmountReservationTransactionForReserveInput"
required: true
callbacks:
notifications:
"{$request.body#/sink}":
post:
security:
- {}
- notificationsBearerAuth: []
tags:
- Payment Notifications
summary: Carrier Billing payment notifications
operationId: preparePaymentNotification
description: |
Important: This endpoint is exposed by the API client, accepting requests in the defined format.
The Carrier Billing server will call this endpoint whenever any carrier billing related event occurs.
parameters:
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: Creates a new carrier billing payment notification
content:
application/cloudevents+json:
schema:
$ref: "#/components/schemas/CloudEvent"
required: true
responses:
"204":
description: Successful notification
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
"400":
$ref: "#/components/responses/Generic400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/Generic403"
"410":
$ref: "#/components/responses/Generic410"
"429":
$ref: "#/components/responses/Generic429"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
responses:
"201":
description: Created
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/BodyAmountReservationTransactionForReserve"
"400":
$ref: "#/components/responses/Payment2StepPrepareInvalid400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/PaymentPermissionDenied403"
"409":
description: Conflict
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
example:
code: ALREADY_EXISTS
status: 409
message: "Another session is created for the same UE"
"422":
$ref: "#/components/responses/PaymentUnprocessable422"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
/payments/{paymentId}/validate:
post:
security:
- openId:
- carrier-billing:payments:write
tags:
- Two Step Payment
summary: Validate a payment
operationId: validatePayment
description: Validate a given payment with a code, identified by its paymentId. This process is applicable for 2-STEP, when optionally required by business case.
parameters:
- name: paymentId
in: path
description: The payment identifier returned when the payment preparation was created.
schema:
type: string
required: true
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: Payment Validation
content:
application/json:
schema:
$ref: "#/components/schemas/ValidatePayment"
required: true
responses:
"204":
description: Validation Succeeded
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
"400":
$ref: "#/components/responses/ValidatePaymentInvalid400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/Generic403"
"409":
description: Conflict
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
examples:
Generic409:
summary: Conflict
value:
code: ALREADY_EXISTS
status: 409
message: "Payment already validated"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
/payments/{paymentId}/confirm:
post:
security:
- openId:
- carrier-billing:payments:write
tags:
- Two Step Payment
summary: Confirm a payment
operationId: confirmPayment
description: Confirm a reservation of a given payment, identified by its paymentId.
parameters:
- name: paymentId
in: path
description: The payment identifier returned when the payment preparation was created.
schema:
type: string
required: true
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: capture PhoneNumber for payment operation
content:
application/json:
schema:
$ref: "#/components/schemas/PhoneNumber"
required: true
responses:
"202":
description: Payment confirmation accepted
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
"400":
$ref: "#/components/responses/Payment2StepInvalid400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/PaymentConfirmPermissionDenied403"
"404":
$ref: "#/components/responses/Generic404"
"409":
$ref: "#/components/responses/PaymentConfirmConflict409"
"422":
$ref: "#/components/responses/PaymentSecondStepUnprocessable422"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
/payments/{paymentId}/cancel:
post:
security:
- openId:
- carrier-billing:payments:write
tags:
- Two Step Payment
summary: Cancel a payment
operationId: cancelPayment
description: Cancel a reservation of a given payment, identified by its paymentId.
parameters:
- name: paymentId
in: path
description: The payment identifier returned when the payment preparation was created.
required: true
schema:
type: string
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: capture PhoneNumber for payment operation
content:
application/json:
schema:
$ref: "#/components/schemas/PhoneNumber"
required: true
responses:
"202":
description: Payment Cancellation Accepted
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
"400":
$ref: "#/components/responses/Payment2StepInvalid400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/PaymentCancelPermissionDenied403"
"404":
$ref: "#/components/responses/Generic404"
"409":
$ref: "#/components/responses/PaymentCancelConflict409"
"422":
$ref: "#/components/responses/PaymentSecondStepUnprocessable422"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
components:
securitySchemes:
openId:
type: openIdConnect
openIdConnectUrl: https://example.com/.well-known/openid-configuration
notificationsBearerAuth:
type: http
scheme: bearer
bearerFormat: "{$request.body#/sinkCredential.credentialType}"
schemas:
CreatePayment:
type: object
required:
- amountTransaction
properties:
amountTransaction:
$ref: "#/components/schemas/AmountTransactionInput"
sink:
type: string
format: url
description: The address to which events shall be delivered, using the HTTP protocol.
example: "https://endpoint.example.com/sink"
sinkCredential:
allOf:
- description: A sink credential provides authentication or authorization information necessary to enable delivery of events to a target.
- $ref: "#/components/schemas/SinkCredential"
PaymentCreated:
type: object
required:
- amountTransaction
- paymentId
- paymentStatus
- paymentCreationDate
properties:
paymentId:
type: string
description: Unique Identifier of the payment
example: "AK234rfweSBuWGFUEWFGWEVWRV"
amountTransaction:
$ref: "#/components/schemas/AmountTransaction"
paymentStatus:
type: string
description: Specifies the payment status (`processing`, `pending_validation`, `denied`, `reserved`, `succeeded`, `cancelled`).
example: "processing"
paymentCreationDate:
type: string
format: date-time
description: Date time when the payment is created in server database. This is a technical information. It must follow RFC 3339 and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z).
paymentDate:
type: string
format: date-time
description: Date time when the payment is effectively performed. This is a business information. It must follow RFC 3339 and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z).
sink:
type: string
format: url
description: The address to which events shall be delivered, using the HTTP protocol.
example: "https://endpoint.example.com/sink"
sinkCredential:
allOf:
- description: A sink credential provides authentication or authorization information necessary to enable delivery of events to a target.
- $ref: "#/components/schemas/SinkCredential"
PaymentArray:
description: A list of payment(s)
type: array
minItems: 0
items:
$ref: "#/components/schemas/Payment"
Payment:
type: object
required:
- amountTransaction
- paymentId
- paymentStatus
- paymentCreationDate
properties:
paymentId:
type: string
description: Unique Identifier of the payment
example: "AK234rfweSBuWGFUEWFGWEVWRV"
amountTransaction:
$ref: "#/components/schemas/AmountTransaction"
paymentStatus:
type: string
description: Specifies the payment status (`processing`, `pending_validation`, `denied`, `reserved`, `succeeded`, `cancelled`).
example: "processing"
paymentCreationDate:
type: string
format: date-time
description: Date time when the payment is created in server database. This is a technical information. It must follow RFC 3339 and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z).
paymentDate:
type: string
format: date-time
description: Date time when the payment is effectively performed. This is a business information. It must follow RFC 3339 and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z).
sink:
type: string
format: url
description: The address to which events shall be delivered, using the HTTP protocol.
example: "https://endpoint.example.com/sink"
sinkCredential:
allOf:
- description: A sink credential provides authentication or authorization information necessary to enable delivery of events to a target.
- $ref: "#/components/schemas/SinkCredential"
SinkCredential:
type: object
properties:
credentialType:
type: string
enum:
- PLAIN
- ACCESSTOKEN
- REFRESHTOKEN
description: "The type of the credential. Only `ACCESSTOKEN` is supported so far."
discriminator:
propertyName: credentialType
mapping:
PLAIN: "#/components/schemas/PlainCredential"
ACCESSTOKEN: "#/components/schemas/AccessTokenCredential"
REFRESHTOKEN: "#/components/schemas/RefreshTokenCredential"
required:
- credentialType
PlainCredential:
type: object
description: A plain credential as a combination of an identifier and a secret.
allOf:
- $ref: "#/components/schemas/SinkCredential"
- type: object
required:
- identifier
- secret
properties:
identifier:
description: The identifier might be an account or username.
type: string
secret:
description: The secret might be a password or passphrase.
type: string
AccessTokenCredential:
type: object
description: An access token credential.
allOf:
- $ref: "#/components/schemas/SinkCredential"
- type: object
properties:
accessToken:
description: REQUIRED. An access token is a previously acquired token granting access to the target resource.
type: string
accessTokenExpiresUtc:
type: string
format: date-time
description: REQUIRED. An absolute UTC instant at which the token shall be considered expired.
accessTokenType:
description: REQUIRED. Type of the access token (See [OAuth 2.0](https://tools.ietf.org/html/rfc6749#section-7.1)).
type: string
enum:
- bearer
required:
- accessToken
- accessTokenExpiresUtc
- accessTokenType
RefreshTokenCredential:
type: object
description: An access token credential with a refresh token.
allOf:
- $ref: "#/components/schemas/SinkCredential"
- type: object
properties:
accessToken:
description: REQUIRED. An access token is a previously acquired token granting access to the target resource.
type: string
accessTokenExpiresUtc:
type: string
format: date-time
description: REQUIRED. An absolute UTC instant at which the token shall be considered expired.
accessTokenType:
description: REQUIRED. Type of the access token (See [OAuth 2.0](https://tools.ietf.org/html/rfc6749#section-7.1)).
type: string
enum:
- bearer
refreshToken:
description: REQUIRED. An refresh token credential used to acquire access tokens.
type: string
refreshTokenEndpoint:
type: string
format: uri
description: REQUIRED. A URL at which the refresh token can be traded for an access token.
required:
- accessToken
- accessTokenExpiresUtc
- accessTokenType
- refreshToken
- refreshTokenEndpoint
AmountTransaction:
required:
- phoneNumber
- paymentAmount
- referenceCode
type: object
properties:
phoneNumber:
type: string
description: |-
Identifies the mobile account to be charged.
A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, prefixed with '+'.
pattern: '^\+[1-9][0-9]{4,14}$'
example: "+34671999000"
clientCorrelator:
type: string
description:
Uniquely identifies this create payment request. If there is
a communication failure during the payment request, using the same clientCorrelator
when retrying the request allows the operator to avoid applying the same
charge twice. This field SHOULD be present. Same value as indicated in the request.
example: "req-12f2pgh448gh2hvrfrv"
paymentAmount:
$ref: "#/components/schemas/PaymentAmountForCharge"
referenceCode:
type: string
description:
Merchant generated payment reference to uniquely identify the
request, for instance, in the case of disputes. Same value as the one provided in the request.
example: "ref-pay-834tfr2rA3v8r8vr3rv"
resourceURL:
type: string
description: URI of the created resource (same as in the Location header)
example: "urn:payments:AK234rfweSBuWGFUEWFGWEVWRV"
serverReferenceCode:
type: string
description:
Reference to the charge or refund, provided by the server,
and meaningful to the server’s backend system for the purpose of reconciliation.
example: "ref-pay-834tfr2rA3v8r8vr3rv-serv"
AmountTransactionInput:
type: object
required:
- paymentAmount
- referenceCode
properties:
phoneNumber:
type: string
description: |-
Identifies the mobile account to be charged.
A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, prefixed with '+'.
Additional Considerations:
- When phoneNumber is not indicated, it can be inferred from authorization context (i.e. token), otherwise `HTTP 403` will be answered.
- When phoneNumber is indicated, authorization context will be consistent, otherwise `HTTP 403` will be answered.
pattern: '^\+[1-9][0-9]{4,14}$'
example: "+34671999000"
clientCorrelator:
type: string
description:
Uniquely identifies this create payment request. If there is
a communication failure during the payment request, using the same clientCorrelator
when retrying the request allows the operator to avoid applying the same
charge twice. This field SHOULD be present.
example: "req-12f2pgh448gh2hvrfrv"
paymentAmount:
$ref: "#/components/schemas/PaymentAmountForCharge"
referenceCode:
type: string
description:
Merchant generated payment reference to uniquely identify the
request, for instance, in the case of disputes.
example: "ref-pay-834tfr2rA3v8r8vr3rv"
PaymentAmountForCharge:
type: object
required:
- chargingInformation
properties:
chargingInformation:
$ref: "#/components/schemas/ChargingInformation"
chargingMetaData:
$ref: "#/components/schemas/ChargingMetaData"
paymentDetails:
$ref: "#/components/schemas/PaymentDetails"
PhoneNumber:
type: object
properties:
phoneNumber:
type: string
description: |-
Identifies the mobile account to be charged.
A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, prefixed with '+'.
Additional Considerations:
- When phoneNumber is not indicated, it can be inferred from authorization context (i.e. token), otherwise `HTTP 403` will be answered.
- When phoneNumber is indicated, authorization context will be consistent, otherwise `HTTP 403` will be answered.
pattern: '^\+[1-9][0-9]{4,14}$'
example: "+34671999000"
ValidatePayment:
type: object
required:
- authorizationId
- code
properties:
authorizationId:
type: string
description: Unique authorization identifier for a specific payment.
example: "Fn34o8g239v3wrb3t"
code:
type: string
description: Code received via SMS to validate and authorize a specific payment, only needed when business case requires it. Sending of this code is outside this specification.
example: "352673"
BodyAmountReservationTransactionForReserve:
required:
- amountTransaction
- paymentId
- paymentStatus
- paymentCreationDate
type: object
properties:
paymentId:
type: string
description: Unique Identifier of the payment
example: "AK234rfweSBuWGFUEWFGWEVWRV"
amountTransaction:
$ref: "#/components/schemas/AmountReservationTransactionForReserve"
paymentStatus:
type: string
description: Specifies the payment status (`processing`, `pending_validation`, `denied`, `reserved`, `succeeded`, `cancelled`).
example: "processing"
paymentCreationDate:
type: string
format: date-time
description: Date time when the payment is created in server database. This is a technical information. It must follow RFC 3339 and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z).
validationInfo:
allOf:
- $ref: "#/components/schemas/ValidationInfo"
- description: Information to perform otp validation. Only needed when business case requires it. Sending of OTP is outside the scope of this specification.
sink:
type: string
format: url
description: The address to which events shall be delivered, using the HTTP protocol.
example: "https://endpoint.example.com/sink"
sinkCredential:
allOf:
- description: A sink credential provides authentication or authorization information necessary to enable delivery of events to a target.
- $ref: "#/components/schemas/SinkCredential"
BodyAmountReservationTransactionForReserveInput:
required:
- amountTransaction
type: object
properties:
amountTransaction:
$ref: "#/components/schemas/AmountReservationTransactionForReserveInput"
sink:
type: string
format: url
description: The address to which events shall be delivered, using the HTTP protocol.
example: "https://endpoint.example.com/sink"
sinkCredential:
allOf:
- description: A sink credential provides authentication or authorization information necessary to enable delivery of events to a target.
- $ref: "#/components/schemas/SinkCredential"
AmountReservationTransactionForReserve:
required:
- phoneNumber
- paymentAmount
- referenceCode
type: object
properties:
phoneNumber:
type: string
description: |-
Identifies the mobile account to be charged.
A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, prefixed with '+'.
pattern: '^\+[1-9][0-9]{4,14}$'
example: "+34671999000"
clientCorrelator:
type: string
description: Uniquely identifies this payment request. If there is
a communication failure during the payment request, using the same clientCorrelator
when retrying the request allows the operator to avoid applying the same
charge twice. This field SHOULD be present. Same value as indicated in the request.
example: "req-12f2pgh448gh2hvrfrv"
paymentAmount:
$ref: "#/components/schemas/PaymentAmountForReserve"
referenceCode:
type: string
description:
Merchant generated payment reference to uniquely identify the
request, for example, in the case of disputes. Same value as the one provided in the request.
example: "ref-pay-834tfr2rA3v8r8vr3rv"
resourceURL:
type: string
description: URI of the created resource (same as in the Location header)
example: "urn:payments:AK234rfweSBuWGFUEWFGWEVWRV"
serverReferenceCode:
type: string
description:
Reference to the charge or refund, provided by the server,
and meaningful to the server’s backend system for the purpose of reconciliation.
example: "ref-pay-834tfr2rA3v8r8vr3rv-serv"
AmountReservationTransactionForReserveInput:
type: object
required:
- paymentAmount
- referenceCode
properties:
phoneNumber:
type: string
description: |-
Identifies the mobile account to be charged.
A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, prefixed with '+'.
Additional Considerations:
- When phoneNumber is not indicated, it can be inferred from authorization context (i.e. token), otherwise `HTTP 403` will be answered.
- When phoneNumber is indicated, authorization context will be consistent, otherwise `HTTP 403` will be answered.
pattern: '^\+[1-9][0-9]{4,14}$'
example: "+34671999000"
clientCorrelator:
type: string
description:
Uniquely identifies this create payment request. If there is