Please see: Vipps MobilePay Technical Documentation: https://developer.vippsmobilepay.com
Home Page: https://developer.vippsmobilepay.com
ℹ️ Please use the website: Vipps MobilePay Technical Documentation.
This endpoint:
https://vippsas.github.io/vipps-ecom-api/#/Vipps%20eCom%20API/cancelPaymentRequestUsingPUT
Returns this:
Server error: `PUT https://apitest.vipps.no/ecomm/v2/payments/ord-10-t-1622723464/cancel` resulted in a `500 APIM Internal Server Error` response:
{"responseInfo":{"responseCode":500,"responseMessage":"Something went wrong, please try again later."}
Even before the phone number has been inserted.
Short term solution:
It should be possible to cancel a charge until the transaction has been sent to the PSP and if the transaction process has been started, the API should return information about the transaction is being processed by a third party PSP, not return 500 server error.
Long term solution:
A started transaction with the PSP should be reversible/'possible to abort' so a cancellation always will be possible until a charge has been completed.
The issue looks very similar to vippsas/vipps-recurring-api#111
PUT https://apitest.vipps.no/ecomm/v2/payments/{id}/cancel
gives
500 APIM Internal Server Error - Something went wrong, please try again later.
when charge is still PENDING
Explanation:
If customer goes to a webpage (using a computer), buys a product & comes all the way to the app (using mobile phone) where the last step is to only click the 'Betal' button and skips to press the 'Betal' button, then goes back to the webpage, selects another product which should be a REPLACEMENT of the first selected product, initiates a new payment, the old payment is still visible in app.
The reason is because there is no way to cancel a PENDING charge as it gives error similar to what the recurring endpoint does.
Fallback URL doesn't have to be publicly available. It must only be reachable from browser that initiates payment.
Callback: Transaction Update is a request sent from Vipps same as shippingdetailsprefix and Consentremovalprefix
Description:
It is a bit frustrating that localhost cannot be used as fallback url for development, as this is normally how developers are testing the workflow.
Replacing http://localhost:8080/vipps with http://example.com/vipps lets the request through, but using localhost does not work with any ports.
Endpoint: https://vippsas.github.io/vipps-ecom-api/shins/index.html#initiate-payment
Request:
{
"merchantInfo": {
"merchantSerialNumber": "{{merchantSerialNumber}}",
"callbackPrefix":"https://example.com/v1/callback/vipps",
"fallBack": "http://localhost:8080/vipps",
"isApp":false
},
"customerInfo": {
"mobileNumber": "{{mobileNumber}}"
},
"transaction": {
"orderId": "{{orderId}}",
"amount": {{amount}},
"transactionText": "{{transactionTextInitiate}}",
"skipLandingPage": false
}
}Error msg:
[
{
"errorGroup": "Merchant",
"errorCode": "merchantInfo.fallBack.invalid",
"errorMessage": "Invalid fallback URL",
"contextId": "7ba66420-6ead-404f-831c-7518f02a4bee"
}
]Ref: #53
Reported as an internal issue, but also mentioned here for reference.
Would there be a way to have the displayed order id be different from the internal {orderId} used for all other purposes?
The orderId in our system might be a really long uuid, but ideally I'd like to show something more friendly in the app.
Hello!
I'm woking on an integration to this API, and want to use the "Direct capture" functionality. But I can't seam to find a good description on how to utilize it.
In the documentation it says:
Direct capture is not depicted on diagram above but, in essence, combines two steps (reserve and
capture) in one. This is a configuration in Vipps backend when Initiate payment request is sent.
I understand this as there being a way to initiate the payment request with a "flag" of some sort saying "directCapture".
Any way someone could help me out here? And maybe update the documentation with a description on how to use this?
Hi Tema, I am integrating payment with vipps to an iOS App and what I have noticed in a particular scenario is that, after making payment in vipps, the Vipps app is not invoking the fallback url to deep link back to the merchant app.
I am initiating the vipps payment with the parameter "isApp": true to perform deeplinking with app and this issue happens for a particular scenario explained below.
The flow works as expected for vipps initiate payment with the required details, and I get the deeplinking url to open the vipps app successfully to prompt for the payment. so far no problem.
But when you tap on pay some times vipps app prompts to enter pin. In this specific case when it prompts to enter pin, if you enter pin the payment is successful but it will not invoke or open the fallback url to deeplink back to the customer app to poll for status. Also noticed in this scenario, even though the payment is shown successful in vipps app, vipps is also not invoking the call-back url to notify the status as reserved to the backend. This is causing an bad experience to the user who pays in vipps.
I face this in Merchant Test app and would like to know if this can be fixed be at your end before I switch my configuration to production and make live payments.
FetchShippingCostAndMethod has two identical properties: postCode and postalCode. According to docs former is required and latter is optional. Both must be four digits but example documentation shows 3 digit number.
See
vipps-ecom-api/docs/swagger.yaml
Lines 1458 to 1469 in 9ac4024
Hi, I tried following the steps shown in https://www.vipps.no/developers-documentation/ecom/documentation/#app-switching
Redirect back to merchant app by simply closing the Vipps app
With this approach, the merchant app does not have to register/handle deeplink urls.In order to use this approach, when creating the payment in the merchant has to pass fallback attribute like this:
"fallBack": "INTENT"
(and only "INTENT"", no parameters etc.)
This will cause the Vipps app to simply close after a successful or canceled ecom payment, and fall back to the calling merchant app.
Fallback 'INTENT' on iOS opens up browser with url: 'https://intent/?status=202', any ideas as to why?
This is not the case for Android, here the app switches back to my app.
Initiate payment: It would help if the alternative values for paymentType were listed as enums, not "just a string". Should be detailed both in the .md and Swaggers.
In the PDF documentation version 2.1, the error response JSON representation is described under section 8. Response codes. This type does not exist anywhere in the Swagger documentation.
The same is true for the error type for the access token service described in section 3.2.10 Error Response Body.
According to the markdown docs, the following are valid transaction statuses in the callback: RESERVED, SALE, RESERVE_FAILED, SALE_FAILED, CANCELLED, REJECTED
In the Swagger docs, the following are valid statuses: RESERVE, SALE, CANCELLED, REJECTED, AUTO_CANCEL
Some overlap, others are either missing in one or the other, or spelled differently (RESERVE vs RESERVED).
Am I mixing up what the callback statuses in the markdown docs are referring to, or is one of the documentations incorrect?
This #98 issue is happening again on VIPPS Test Environment.
Getting a 400 response for my requests with error:
{
"errorGroup": "Merchant",
"errorCode": "Invalid IP address",
"errorMessage": "Invalid IP address",
"contextId": "ed9f848e-8a76-4d66-ac75-c1df9d011fa3"
}
when the URLs in the request start with http://127.0.0.1
e.g: http://127.0.0.1/vipps/payment/done/123
I'm familiar with getting it working as I have the same URL working fine for Recurring API but not for ECommerce API
Hi,
I get this callback during testing with MT:
This one if I cancel the payment on the desktop:
'{"merchantSerialNumber":"226745","orderId":"PR76TPDB","transactionInfo":{"amount":654,"status":"REJECTED","timeStamp":"2021-10-01T08:42:41.775Z"},"errorInfo":{"errorCode":"45","errorGroup":"PAYMENTS","errorMessage":"User has not acted upon the payment"}}'
And this one if I cancel in the Vipps app:
'{"merchantSerialNumber":"226745","orderId":"F0CXQNSA","transactionInfo":{"transactionId":"5002819898","amount":654,"status":"CANCELLED","timeStamp":"2021-10-01T12:38:54.685Z"}}
And this one if I forget to klick pay in the MT App:
'{"merchantSerialNumber":"226745","orderId":"9RIE7UNS","transactionInfo":{"transactionId":"5002819953","amount":654,"status":"REJECTED","timeStamp":"2021-10-01T11:11:15.696Z"},"errorInfo":{"errorCode":"45","errorGroup":"PAYMENTS","errorMessage":"User has cancelled or not acted upon the payment"}}'
Why is 1) AND 3) Identical (or 1) correctly stating 'User has cancelled?
/ Digiloo
`
Just like #114
Hi! 😁
We are now implementing two new checkout integrations for a customer and have started the onboarding process using this scheme: https://vippsbedrift.no/signup/vippspanett/ & we are happy to see that the keys is now to be found at portal.vipps.no instead of the old interface which we found hard to work with.
So the request has been approved, but some API keys is still missing.
1st:
We can see the Vipps-eCommerce-Services product in the list which has:
But, we do not have access to the auth token API and we can't find the Primary Key for the auth api anywhere. 😱 (Edit: I refer to the JWT access token, see image in the first comment below)
This is also the case for previous integrations where we already have the codes. All codes and products is displayed in the list except for the Primary Key for the auth / token service. Without this code it is not possible to use any endpoints, because you cant generate an access token without it.
For the companies we previously integrated with vipps we do at least find the eCommerce-Classic-Services in the list which is good.
In summary:
At the onboarding process you should not only give access to the API V2, but also the Auth API and API V1 by default / always.
Why Auth API?
API V2 can't be used without the Auth API. (Edit: Here I ment the JWT Access token. It looks like it is supposed to be available on the portal some where, but I cant find it.)
Why API V1 (classic)?
Checkout with V2 REQUIRES a BROWSER and that the customer leaves the shop / app.
This means that it will not work with certain software where a web browser is not intended (as in our use case). (Edit: I now see that this is deprecated, ref. screenshot in first comment. That is not good news for us, so I created a new issue on it. -> #78)
When using API V1 (classic) this is not a problem, but with V2 it is a problem.
For example - We use it for a "Self service POS". and don't want to add a web-browser to it (neither a popup / iframe).
I also send this by e-mail to [email protected]
authToken is missing/unclear in several places.
Documentation says: "URLs that start with https://localhost will be rejected. If you want to use localhost as fallback, please use http://127.0.0.1", but this do not work.
When fallBack is set to "http://127.0.0.1/vipps/complete/useridabc123" error response is randomly changing between this two responses:
[ { "errorGroup": "Merchant", "errorCode": "Invalid IP address", "errorMessage": "Invalid IP address", "contextId": "6f90fd24-465d-469f-9288-8b8b7003dc3d" } ]
and sometimes
[ { "errorGroup": "Merchant", "errorCode": "{merchantInfo.fallback.URL.IPAddress.invalid}", "errorMessage": "{merchantInfo.fallback.URL.IPAddress.invalid}", "contextId": "6699dcf9-d8e4-4946-94cc-ca9e8900c71d" } ]
I am using API-keys for VIPPS test environment.
Api v1 should be available when moving to v2 using same auth keys.
Its a bit frustrating moving to v2 with regularly and breaking changes from v1 without having the stable functionality which was working in v1.
Having v1 also available in v2 would fix this and could let us play around with v2 until its stable while using v1 for public applications.
I've had a hard time integrating Vipps into some products. It is solely because of how the documentation is structured. It seems kind of like... a mess.
When I read documentation for services, I'm used to it being written with a perspective that helps me achieve my goals.
The documentation I've found for Vipps integration seems like it's just a knowledge dump with little to no structure.
It does not display a clear path to achieving the end goals for integrators (e.g. "steps to integrate for android", "steps for integrating with a web project", etc.) and it uses terms without ever explaining what they mean.
I'm sorry to say it, but something that could have taken 30 minutes to implement ended up taking days due to the documentation (and I've heard others have spent way more than that).
The documentation is currently 34 pages long (A4).
The parts I ended up using for a web integration could probably have been condensed down to three pages.
It says in the docs that the merchantSerialNumber should be defined like this:
merchantSerialNumber* | string
minLength: 6
maxLength: 6
example: 123456
pattern: ^\d{6}$
Our company's msn is a 5 numbered number. Should it be prefixed in some way (update docs), or is the constraint wrong (update docs)?
Would be really nice to have a Healthcheck/Ping/Status endpoint to be able to test that a connection can be made to the API with the current credentials.
The generated proxy-class from swagger does not deserialize the response data into an object if the response status is 200 (OK). It only returns default(InitiatePaymentV2Representation) which is NULL
Allow a merchant to specify an expiry date for a given transaction instead of today's hard coded limit of 4 minutes.
Examples for both payment types should be in both Swagger and Markdown.
These three are very similar, with the only difference being the status example and enum (all three have a status enum with one item btw):
TransactionInfoCancelTransactionInfoRefundTransactionInfoCaptureCan we merge them into a common TransactionInfo? (Transaction is used for something else)
TransactionInfoCancel:
type: object
required:
- amount
- status
- timeStamp
- transactionId
- transactionText
properties:
amount:
type: number
format: double
description: Ordered amount in øre
example: 20000
status:
type: string
enum:
- Cancelled
example: Cancelled
description: >-
Status which gives the current state of the payment within Vipps.
See the [API
guide](https://github.com/vippsas/vipps-ecom-api/blob/master/vipps-ecom-api.md#responses-from-requests)
for more information.
timeStamp:
type: string
description: Timestamp in ISO-8601 representing when the order was cancelled.
example: '2018-12-12T11:18:38.246Z'
transactionId:
type: string
description: Vipps transaction id
example: '5001420062'
transactionText:
type: string
description: Transaction text to be displayed in Vipps
example: One pair of Vipps socks
maxLength: 100
I'm getting the following error or calling with a proper orderId https://apitest.vipps.no/ecomm/v2/integration-test/payments/{orderId}/approve
Request
{ "customerPhoneNumber": "phone number used in initiating the payment", "token": "token copied from initial url (token parameter)" }
Response
[ { "errorGroup": "Customer", "errorCode": "81", "errorMessage": "Invalid phone number for test. Use a proper test number instead", "contextId": "36fae2cc-c457-47a4-a68c-6723f9e949ce" } ]
expressCheckOutPaymentRequest is listed in the Swagger docs, but I can't find a way to see the regular callback payload?
The documentation mentions "fallback" URLs. These seem to not be fallback URLs at all, but main flow URLs. The use of the word "fallback" should be used only if referring to something like an error page or out of service page - things that we fall back to when something goes wrong or takes an unexpected turn.
Address model documentation uses zipCode field while the field available in the response has postCode property, rather than zipCode.
Compare
vipps-ecom-api/docs/swagger.yaml
Lines 809 to 812 in 9ac4024
{"address": {"addressLine1":"a","addressLine2":"b","postCode":"1234","city":"c","country":"Norway"}
Hi!
If try to refund more than captured amount an error will be returned (as expected), but errorCode set as string.
In all other cases errorCode returned as integer.
[
{
"errorGroup":"Payment",
"errorCode":"71",
"errorMessage":"Can't refund more than captured amount",
"contextId":"cd391e18-2e88-43ef-b540-d841deb1db20"
}
]
I think will be better for consistency to use the same type everywhere.
Found this in the pdf documentation and swagger doc:
[callbackPrefix]/v2/payments/{orderId}
All requests under "Complete HTTP requests and responses for each API endpoint and method" should have headers (possibly with tokens truncated for readability):
shippingDetails callback requires both shippingMethod and shippingMethodId to be set. But when Payment is completed only shippingMethod is available in:
Multiple shipping methods can have identical shippingMethod so shippingMethodId is mandatory to determine which method customer selected.
I got the following response from a force approve, but can find the error code 1082 documented.
Array (
0 =>
(object) array(
'errorGroup' => 'Payment',
'errorCode' => '1082',
'errorMessage' => '1082',
'contextId' => '36c2eaf4-8795-4e06-bb85-ff289e640131',
),
)
/ Digiloo
When the fallback/callback url is considered invalid - local or does't validate with UrlValidator - misleading error message is dispatched, giving bad DX (Developer Experience):
merchantInfo.fallBack.invalid: Fallback should not be null or empty
for fallback url: http://localhost/fallback
The error message should reflect that fallback url is invalid, rather than null or empty.
Hello, I have seem to gotten a error code 7 when launching my Vipps app from my Oneplus 6 running android 10 and same issue on android 11. Do you guys have any clue what this is? Where as the error code is not on the list on the dev page (https://www.vipps.no/developers-documentation/ecom/documentation/#error-codes)
Trying to accept payment in app, gives following error: saleid unit is null
Platform: Android
Vipps app version: 1.9.1
Vipps api version: v2
Endpoint: https://api.vipps.no/ecomm/v2/payments
Request with following body fails:
{
"merchantInfo": {
"merchantSerialNumber": "100948",
"callbackPrefix":"https://api.vipps.no/api/callback",
"fallBack":"https://api.vipps.no/api/callback",
"paymentType":"eComm Express Payment",
"isApp": false
},
"customerInfo": {
"mobileNumber": "93977183"
},
"transaction": {
"orderId": "test123696",
"amount": "9999",
"transactionText":"11233121"
}
}
But when removing paymentType it works:
{
"merchantInfo": {
"merchantSerialNumber": "100948",
"callbackPrefix":"https://api.vipps.no/api/callback",
"fallBack":"https://api.vipps.no/api/callback",
"isApp": false
},
"customerInfo": {
"mobileNumber": "93977183"
},
"transaction": {
"orderId": "test123696",
"amount": "9999",
"transactionText":"11233121"
}
}
If paymentType is added, app says 'Beregner frakt' before it crashes.
If paymentType is kept out, 'Beregner frakt' does not appear and payment passes successfully.
Any advice here please? :)
It's kind of cumbersome to read the JSONS.
It would be nice if the docs were served by a webserver somewhere and that the README
contained a link to said server.
Hi!
I'm working on integrating the Vipps payment flow into my app and just hit a wall with deep links.
When I initiate a new payment with "isApp: true" i get a link back like this: vipps://?token=.... This opens the production version of the Vipps app, but when I'm working in test, it should go to the test version.
Do you guys have any trick I can to to make it go to the "test" app? Ex replace vipps:// with the scheme of the test app? If so, what is it? 😄
Ps: I'm working on the iOS versjon of the app right now.
Cheers,
Ole
When I cancel a payment on this screen than I don't get any TransactionLogHistory with "Cancel" PaymentOperation while calling /ecomm/v2/payments/{orderId}/details endpoint.
It works when I cancel either before I provide a phone number or in the Vipps test app.
Any ideas why?
Hello!
Thanks for great API documentation, but could you tell me what is the max length of transactionText for Capture, Refund, and Cancel actions?
Is it the same 100 chars as in the TransactionInfoInitiateDTO?
TransactionInfoInitiateDTO:
...
transactionText:
type: string
description: Transaction text that can be displayed to end user
maxLength: 100
example: One pair of Vipps socks
I just logged in to the old portal and found this (says API V1 is deprecated):
Why this is a problem
Many of our integrations is heavily based on it because it has a feature which is not supported in API v2. It will cause trouble for multiple systems which has been live for already over a year & also upcoming projects which is still in the developer stage and soon ready to be published.
The missing functionality in V2
The functionality I am referring to is the following endpoint:
POST request to https://api.vipps.no/Ecomm/v1/payments
What V1 does
It initiates the payment process right away which is perfect. 🤗
The user can just open the App and accept!
What V2 does
It returns a link which customer has to follow (Either a webbrowser link or a deeplink.) 🤔
The user has to go to another page and click another button.
Good with V1
It doesn't require a browser to initiate the payment, but it can be directly initiated from any app or payment service application. The initiation requires one less step and is faster on the web! (when not using mobile deeplink).
Bad with V1
It does not have the option with deeplink for mobile.
Good with V2
It has the option for deeplinking on mobile devices (Express checkout).
Bad with V2
It removes the option for customized payment initiation triggers.
It requires the user to follow the link.
It is slower (Express checkout is true for mobile deeplink, but false for desktop checkout).
It will make some systems stop working when V1 is removed and scratch some ongoing projects for us at least
Hope you can help out our frustrations 😅
I dokumentasjonen står det at det returneres "TransactionInfo" i refund kallet:
vipps-ecom-api/docs/swagger.json
Line 1261 in dc8b8f8
I realiteten returneres "Transaction".
API burde oppdateres til å reflektere dokumentasjon, jeg hadde forventet å få TransaksjonInfo tilbake her slik som i de andre kallene.
Eventuelt så burde dokumentasjonen oppdateres til å reflektere det faktiske svaret som kommer tilbake.
Æ Ø Å not rendered on checkout page, please fix.
Endpoint
https://api.vipps.no/ecomm/v2/payments
Problem
Initiate payment endpoint in v2 does not support direct trigger for payments trough api in app.
Actual behaviour
Endpoint returns json with external checkout url & orderid
{
"orderId": "string",
"url": "string"
}
Expected behaviour
Should be an option to trigger payment from app directly like in v1 which returns
{
"orderId": "219930212",
"merchantSerialNumber": "NSBWSHP12",
"transactionInfo": {
"amount" : 1200,
"status": "Initiate",
"transactionId": "1001234566",
"timeStamp": "2014-06-24T08:34:25-07:00",
"message":"Please use vipps app to process the payment"
}
}
Its nice to have the option to use checkout url from vipps, but this should be optional.
Why?
How?
Could possibly be fixed by adding a queryparam with manual_checkout set to true and use functionality in api v1. Ex.
The chapter contains a "the the" that probably shall be "to the"
The error I'm getting:
{
"error":"unauthorized_client",
"error_description":"AADSTS700016: Application with identifier \'my_client_id\' was not found in the directory \'tenant_directory\'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.",
"error_codes":[700016],
"timestamp":"2021-03-23 06:46:31Z",
"trace_id":"xxx",
"correlation_id":"xxx",
"error_uri":"https://login.windows.net/error?code=700016"
}POST Request to: /accesstoken/get
The headers are properly formed, and I have quadruple checked all the keys. I am sending the keys in the HEADERS, to the test URL. From what I gather from your FAQ is that this error occurs when you send the wrong key to the wrong endpoint. I however do know with 100% certainty that these are the correct keys. This is also getting sent to the correct server (the test server).
Have I been banned or something? 😄
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.