Skip to content

Commit 8f23df7

Browse files
HenrietteBossenHenrietteBossen
authored
Update test.mdx
1 parent 5d021c5 commit 8f23df7

File tree

1 file changed

+1
-191
lines changed
  • docs/subscriptions/development-guide

1 file changed

+1
-191
lines changed

‎docs/subscriptions/development-guide/test.mdx

+1-191
Original file line numberDiff line numberDiff line change
@@ -7,194 +7,4 @@ import TabItem from "@theme/TabItem"
77

88
# Test
99

10-
In this section, you can find information on testing in sandbox, as well as how to get test data. The Sandbox is a special environment designed just for testing, and an application that targets the Sandbox can perform all the operations it can in the Production environment. However, all users, items, and payments involved in Sandbox transactions are fictitious. To ensure a good user experience, we recommend you to test your solution thoroughly before launching.
11-
12-
## Testing API
13-
14-
We supply a testing API, that simulates user actions in the app. With the API you can do the following:
15-
16-
* Accept and reject an agreement
17-
* Cancel agreement
18-
* Reject subscriptions payment
19-
* Accept and reject OneOff payment
20-
21-
You must subscribe to the testing API before you can use it. When calling the testing API, you must always supply an authenticated user id. You can find a list of user ids below in the section about test data. The Subscriptions User Simulation API is available from the Sandbox APIs.
22-
23-
## Sandbox testing
24-
25-
Sandbox testing
26-
You are able to test all the Subscription features, just as they are in the production environment, and you will receive callbacks. You have access to a testing API: Subscriptions User Simulation which makes it possible to imitate user actions. In the [technical documentation](/docs/subscriptions/agreement) you can find flow diagrams, where you can see the app flow.
27-
28-
**Access Token**
29-
When you are calling the API, and when you've been through the OpenID Connect flow, then you should remember to add the access token. All calls to Subscription endpoints require access tokens. The content of the header should look like the following:
30-
31-
```json title="Header examples"
32-
accept: application/json
33-
content-type: application/json
34-
authorization:: REPLACE_THIS_VALUE
35-
```
36-
37-
When you make a payment request, then we validate the request itself, but not the individual payments. So it only validates if you have the required parameters with the correct types. So the response you get for the payment request does not say if the payment is pending, but if the payment creation is pending. Then the payments are processed in our system, and they will either be requested (valid) or declined (invalid). Moreover, you will receive a callback to inform you whether payments are requested or declined. This will be sent to your payment status callback.
38-
39-
![Recurring payment states](/img/subs-payment_states.jpg)
40-
41-
### Difference between sandbox and production
42-
43-
| | Sandbox | "Hidden" production | **Production**|
44-
|--|--|--|--|
45-
|**Purpose**|To test all functionality in a shielded environment|To verify the UX experience and usage patterns. To test checkout flow. To see how transactions appear on the bank account| To offer MobilePay Subscriptions as a payment method for customers|
46-
|**Receive callbacks**|You receive callbacks in sandbox|You receive callbacks in "hidden production"|You receive callbacks in production|
47-
|**User**|MobilePay provides you with a test user below under 'Test data'. The testsuer can be used in sandbox|A real MobilePay user, that has downloaded the MobilePay app on their smartphone. In "hidden production" it is usually the employees that are conducting the testing that is testers|A real MobilePay user, that has downloaded the MobilePay app on their smartphone|
48-
|**Payment limit**|Same as in production. Read [here](https://www.mobilepay.dk/hjaelp/mobilepay-til-private/fakta/hvor-meget-kan-jeg-overfoere-med-mobilepay)|Read [here](https://www.mobilepay.dk/hjaelp/mobilepay-til-private/fakta/hvor-meget-kan-jeg-overfoere-med-mobilepay%20%20)|Read [here](https://www.mobilepay.dk/hjaelp/mobilepay-til-private/fakta/hvor-meget-kan-jeg-overfoere-med-mobilepay)|
49-
|**User simulation**|There isn't a sandbox app for MobilePay. Instead, use the following APIs to simulate user interaction: Subscriptions User Simulation|A real MobilePay user, that has downloaded the MobilePay app on their smartphone. The flow can be experienced from a customer point of view.|A real MobilePay user, that has downloaded the MobilePay app on their smartphone|
50-
|**Functionality**|Same functionality but fake transactions|Same functionality but real transactions.|Same functionality but real transactions|
51-
|**Transaction fee**|Free in sandbox|Transactions in production are not free|Transactions in production are not free|
52-
|**Endpoint**|[https://api.sandbox.mobilepay.dk](https://api.sandbox.mobilepay.dk/)|[https://api.mobilepay.dk](https://api.mobilepay.dk/)|[https://api.mobilepay.dk](https://api.mobilepay.dk/)|
53-
|**Subscriptions/Payment Validation**|1 day|1 day|1 day|
54-
|**Subscriptions API/Visible in the app**|No|No|Yes|
55-
|**Reconciliation**|You cannot test reconciliation in the sandbox, as you will have a fake test user and a fake account. You will not see how the money appears on the bank account.|Yes. The Transaction Reporting Api is available in production|Yes. The Transaction Reporting API is available in production|
56-
57-
:::tip
58-
59-
As far as possible, automate your tests
60-
61-
:::
62-
63-
## Test data
64-
65-
When using the Subscriptions User Simulation API, you must always supply an authenticated user id. Below you can find a list of user ids for Denmark and Finland. If there is an issue with a test user, please try a different user, or contact us at [email protected]
66-
67-
:::note
68-
When testing Subscription payments and one-offs in Sandbox remember to use the same authenticated user id for both creating and approving the payments.
69-
These are only valid on our test platform, and will not result in a real transaction or transfer of funds.
70-
You can test how your integration handles responses from the MobilePay platform by forcing specific result codes.
71-
:::
72-
73-
<Tabs
74-
defaultValue="dk"
75-
values={[
76-
{label: 'DK test users', value: 'dk'},
77-
{label: 'FI test users', value: 'fi'},
78-
]}>
79-
80-
81-
<TabItem value="dk">
82-
83-
|Authenticated user id | Phone number | Consumer name |
84-
|--|--|--|
85-
| f1a75bb4-c8a6-41f8-8603-4cf9278cd5ba | +4557373259 | Test name|
86-
| 4f474aa2-6161-4094-97fd-62616ff3d21e | +4599592431 | Test name*|
87-
| d5e4e229-b482-4304-80f1-237d2a3abc48 | +4522509895 | Test name|
88-
| 40b881f7-ac3d-43bb-81e6-2ac9ef279d89 | +4554048573 | Test name|
89-
| 147a8bbd-6a87-40e7-9980-937d1b8d0de4 | +4585155935 | Test name|
90-
**Card is expired. Use this test user to test error handling for failed card scenarios*
91-
92-
</TabItem>
93-
94-
<TabItem value="fi">
95-
96-
|Authenticated user id | Phone number | Consumer name |
97-
|--|--|--|
98-
| 439d1721-0a36-499f-b236-8bfc61c6cbb7 | +358121161343 | FI Test name|
99-
| f5588bb0-d90d-419f-9ec5-7ef138c23f83 | +358121161892 | FI Test name|
100-
101-
</TabItem>
102-
</Tabs>
103-
104-
Also, familiarize yourself with the steps described in the testing section to find out in which order you should perform these calls. For Subscriptions, we recommend you create an agreement, so you can request a subscription payment on the agreement.
105-
106-
## Making the first calls
107-
108-
Once you have completed the OpenID Connect flow, you are ready to make the first call to our API.
109-
110-
1. Call `GET /api/merchants/me` which will return you a list of subscription providers for that merchant, with their IDs and basic information which you will need in the other API calls.
111-
112-
:::note
113-
Note: If you are an integrator managing the solution for a Merchant, this will be your first task when onboarding them to your platform. The Merchant does not know their SubscriptionsProviderId.
114-
:::
115-
116-
```json title="Request body example"
117-
{
118-
"Id": "5911127561076736",
119-
"SubscriptionProviders": [
120-
{
121-
"SubscriptionProviderId": "00000000-0000-0000-0000-000000000000",
122-
"Name": "Netflix",
123-
"HomepageUrl": "http://netflix.com",
124-
"CustomerServiceEmail": "[email protected]",
125-
"SelfServicePortalUrl": "http://netflix.com/mylogin",
126-
"FaqUrl": "http://netflix.com/faq",
127-
"Status": "active",
128-
"Address": "Rådhuspladsen 1",
129-
"ZipCode": "1550",
130-
"City": "Copenhagen"
131-
}
132-
]
133-
}
134-
```
135-
136-
2. You can then continue by creating your first MobilePay Subscriptions agreement. To create an agreement use `POST /api/providers/{providerId}/agreements`.
137-
138-
Make a `POST` to the endpoint
139-
`https://api.sandbox.mobilepay.dk/subscriptions/api/providers/{providerId}/agreements` (remember to insert your own URLs)
140-
141-
```json title="Request example"
142-
accept: application/json
143-
content-type: application/json
144-
authorization:: REPLACE_THIS_VALUE
145-
146-
{
147-
"external_id":"OrderNumber1",
148-
"amount":10,
149-
"currency":"DKK",
150-
"description":"Home and Car Insurance",
151-
"next_payment_date":"2021-12-16",
152-
"frequency":12,
153-
"links":[
154-
{"rel":"user-redirect","href":"https://example.com/"},
155-
{"rel":"success-callback","href":"https://example.com/"},
156-
{"rel":"cancel-callback","href":"https://example.com/"}],
157-
"country_code":"DK",
158-
"plan":"Insurance",
159-
"expiration_timeout_minutes":5,
160-
"mobile_phone_number": "4511100118",
161-
"retention_period_hours": 0,
162-
"disable_notification_management": false,
163-
}
164-
```
165-
166-
If successful, you will receive a http `201 created` response including an agreement id for the pending agreement, and a link to redirect the user to the pending agreement.
167-
In the sandbox, the link will not be working, instead, you need to use the Subscriptions User Simulation API and the test data we have provided you with, to accept the agreement. Use `PATCH /api/agreements/v1/{id}` to accept the agreement.
168-
Congratulation, you have created your first agreement!
169-
170-
## Testing example - Accept Agreement - 3rd party
171-
172-
When you have created an agreement in the sandbox, you can use the testing API to simulate that a user accepts the agreement.
173-
To accept an agreement you must use `PATCH /api/agreements/v1/{id}` and replace `{id}` with an agreement id.
174-
175-
**Example**
176-
Make a `PATCH` to the endpoint
177-
`https://api.sandbox.mobilepay.dk/recurringpayments-restapi/api/agreements/v1/REPLACE_ID` with the following headers:
178-
179-
```json title="Request example"
180-
accept: application/json
181-
content-type: application/json
182-
authenticateduser: REPLACE_THIS_KEY
183-
184-
{"status":"Accepted"}
185-
```
186-
187-
If successful, you will receive a http `204 No Content` response. We will then send a callback to the success-callback you set, when the agreement was created, to inform you that the agreement has been accepted:
188-
189-
```json title="Callback body example"
190-
{
191-
"agreement_id" : "AGREEMENT_ID",
192-
"status" : "Accepted",
193-
"status_text" : "The agreement has been accepted.",
194-
"status_code" : 0,
195-
"external_id" : "EXTERNAL_ID",
196-
"timestamp" : "2016-08-24T11:42:27+00:00"
197-
}
198-
```
199-
200-
And then you are ready to start requesting payments for the new agreement.
10+
Please read [here](https://developer.mobilepay.dk/docs/subscriptions/transition-to-one-platform#5-will-i-be-able-to-continue-testing-my-integration-in-sandbox)

0 commit comments

Comments
 (0)