Merge pull request #2336 from SwedbankPay/feature/devp-443_external_l…

…ink_tab_in_msdk

DEVP-443: Made external links open in new tab

_includes/cobadge-dankort.md

@@ -1,19 +1,20 @@
 ## Co-badge Card Choice For Dankort
 
-Due to [EU regulations from 2016-06-09][eu-regulation] regarding cards with more
-than one payment application, we have developed support for end users of
-Dankort to be able to choose their preferred payment application on the Swedbank
-Pay payment page. If you are a Dankort user, read more about this feature at
-[Dankort][dankort-eu].
+Due to [EU regulations from 2016-06-09][eu-regulation]{:target="_blank"}
+regarding cards with more than one payment application, we have developed
+support for end users of Dankort to be able to choose their preferred payment
+application on the Swedbank Pay payment page. If you are a Dankort user, read
+more about this feature at [Dankort][dankort-eu]{:target="_blank"}.
 
 As a merchant you can set a priority selection of payment application by
-contacting [Swedbank Pay Support][swedbankpay-support]. The payer will always
-be able to override this priority selection on the payment page.
+contacting [Swedbank Pay Support][swedbankpay-support]{:target="_blank"}.
+The payer will always be able to override this priority selection on the payment
+page.
 
 If you want more information about Co-badge Card Choice for Dankort users,
-please contact [Swedbank Pay Support][swedbankpay-support]. The example below
-shows the payment window where the payer can choose between Dankort or Visa
-before completing the payment.
+please contact [Swedbank Pay Support][swedbankpay-support]{:target="_blank"}.
+The example below shows the payment window where the payer can choose between
+Dankort or Visa before completing the payment.
 
 ## How It Looks
 

_includes/custom-styling.md

@@ -11,7 +11,8 @@ below).
 
 ## Customizable Elements
 
-With the arrival of our [accessibility compliant payment UI][wcag-presentation],
+With the arrival of our
+[accessibility compliant payment UI][wcag-presentation]{:target="_blank"},
 the elements you can adjust are related to the CTA button. Available changes
 are:
 
@@ -49,7 +50,7 @@ You can make the adjustments you want in the `style` object and include it in
 the `style` node of the script that loads the UI.
 
 Do you want to see the changes live before you put them to use? Stop by the
-[Swedbank Pay Playground][playground] and give it a go!
+[Swedbank Pay Playground][playground]{:target="_blank"} and give it a go!
 
 {:.code-view-header}
 **Payment UI loading script**

_includes/instrument-mode.md

@@ -48,9 +48,9 @@ menu.
 Swedbank Pay provides a script to do this check, with the URL
 `ecom.<environment>.payex.com/checkout/core/integration.` Environments
 available for you are `externalintegration` and `production`, and you can switch
-integration between `checkout` and `paymentmenu`. Follow these links for [test
-environment][test-env] and [production environment][prod-env] **Checkout**
-scripts.
+integration between `checkout` and `paymentmenu`. Follow these links for
+[test environment][test-env]{:target="_blank"} and
+[production environment][prod-env]{:target="_blank"} **Checkout** scripts.
 
 Add the script tag to your website and perform the javascript call
 `await payex.getAcceptedWallets()`. We will return a string array with the

_includes/mobile-sdk-debugging.md

@@ -99,7 +99,7 @@ let configuration = SwedbankPaySDK.MerchantBackendConfiguration(
 ```
 
 After you have verified that a domain works with WKWebView, please file an
-[issue][ios-issues] to have it added to the SDK's bundled list.
+[issue][ios-issues]{:target="_blank"} to have it added to the SDK's bundled list.
 
 [ios-issues]: https://github.com/SwedbankPay/swedbank-pay-sdk-ios/issues
 [ios-payment-url]: /checkout-v3/modules-sdks/mobile-sdk/ios#payment-url-and-external-applications

_includes/payment-url.md

@@ -72,9 +72,10 @@ in {% if technical_reference_url contains "/checkout-v2" %}
 {% endif %}
 
 When implementing the Seamless View flow into a WebView in your mobile app, you
-should use a [custom scheme][custom-scheme] or [Universal Link][universal-link]
-in the `paymentUrl` for handling automatic switching between your app and the
-payment app on the mobile device.
+should use a [custom scheme][custom-scheme]{:target="_blank"} or
+[Universal Link][universal-link]{:target="_blank"} in the `paymentUrl` for
+handling automatic switching between your app and the payment app on the mobile
+device.
 
 {% endif %}
 [custom-scheme]: https://developer.apple.com/documentation/uikit/inter-process_communication/allowing_apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app

_includes/user-agent.md

@@ -1,9 +1,9 @@
 ## User-Agent
 
-The term [user agent][user-agent] is used for both the web browser used by the
-payer as well as the system making HTTP requests towards Swedbank Pay's APIs.
-The difference between these two and how they relate to each other is
-illustrated in the below sequence diagram:
+The term [user agent][user-agent]{:target="_blank"} is used for both the web
+browser used by the payer as well as the system making HTTP requests towards
+Swedbank Pay's APIs. The difference between these two and how they relate to
+each other is illustrated in the below sequence diagram:
 
 ```plantuml
 @startuml "User Agents"

checkout-v3/get-started/fundamental-principles.md

@@ -9,11 +9,12 @@ description: |
 
 ## Foundation
 
-The **Swedbank Pay API Platform** is built using the [REST architectural
-style][rest] and the request and responses come in the [JSON] format. The API
-has predictable, resource-oriented URLs and use default HTTP features, like HTTP
-authentication (using OAuth 2), HTTP methods and headers. These techniques are
-widely used and understood by most HTTP client libraries.
+The **Swedbank Pay API Platform** is built using the
+[REST architectural style][rest]{:target="_blank"} and the request and responses
+come in the [JSON] format. The API has predictable, resource-oriented URLs and
+use default HTTP features, like HTTP authentication (using OAuth 2), HTTP
+methods and headers. These techniques are widely used and understood by most
+HTTP client libraries.
 
 ## Connection and Protocol
 
@@ -24,16 +25,17 @@ connecting to Swedbank Pay's APIs. This is most likely due to the connection
 being made from the client with TLS 1.0 or even SSL, which are all insecure and
 deprecated. If such is the case, ensure that you are able to connect over a
 TLS 1.2 connection by reading information regarding your programming languages
-and environments ([Java][java-tls], [PHP Curl][php-curl-tls],
-[PHP Zend][php-zend-tls], [Ruby][ruby-tls], [Python][python-tls],
-[Node.js Request][node-tls]).
+and environments ([Java][java-tls]{:target="_blank"},
+[PHP Curl][php-curl-tls]{:target="_blank"}, [PHP Zend][php-zend-tls],{:target="_blank"}
+[Ruby][ruby-tls]{:target="_blank"}, [Python][python-tls]{:target="_blank"},
+[Node.js Request][node-tls]{:target="_blank"}).
 
-You can inspect [Swedbank Pay's TLS and cipher suite][ssllabs] support at
-SSL Labs. Support for HTTP/2 in our APIs is being investigated.
+You can inspect [Swedbank Pay's TLS and cipher suite][ssllabs]{:target="_blank"}
+support at SSL Labs. Support for HTTP/2 in our APIs is being investigated.
 
 ## Postel's Robustness Principle
 
-We encourage you to keep [Postel's robustness principle][robustness-principle]
+We encourage you to keep [Postel's robustness principle][robustness-principle]{:target="_blank"}
 in mind. Build your integration in a way that is resilient to change, wherever
 it may come. Don't confine yourself to the limits of our current documentation
 examples. A `string` looking like a `guid` must still be handled and stored like
@@ -91,8 +93,8 @@ different operations in the client, this task is moved to the server. The client
 simply follows links and performs operations provided by the API, given the
 current state of the resource. The server controls the state and lets the client
 know through hypermedia what's possible in the current state of the resource. To
-get an [introduction to **hypermedia**, please watch this 20 minute
-video][the-rest-and-then-some].
+get an
+[introduction to **hypermedia**, please watch this 20 minute video][the-rest-and-then-some]{:target="_blank"}.
 
 {% include alert.html type="warning" icon="warning" header="Don't build URLs"
 body=" It is very important that only the base URLs of Swedbank Pay's APIs are
@@ -252,20 +254,20 @@ manner across the entire API Platform.
 
 ### Currency
 
-All currencies are expressed according to the [ISO 4217][iso-4217] standard,
-e.g `SEK`, `EUR`, `NOK`.
+All currencies are expressed according to the
+[ISO 4217][iso-4217]{:target="_blank"} standard, e.g `SEK`, `EUR`, `NOK`.
 
 ### Dates
 
-All dates are expressed according to the [ISO 8601][iso-8601] standard that
-combine dates, time and timezone data into a string, e.g.
+All dates are expressed according to the [ISO 8601][iso-8601]{:target="_blank"}
+standard that combine dates, time and timezone data into a string, e.g.
 `2018-09-14T13:21:57.6627579Z`.
 
 ### Locale
 
-When defining locale, we use the combination of [language][iso-639-1]
-and [country codes][iso-3166]. Our payment menu UI is currently limited to
-`nb-NO`, `sv-SE`, `da-DK` `fi-FI` and `en-US`.
+When defining locale, we use the combination of [language][iso-639-1]{:target="_blank"}
+and [country codes][iso-3166]{:target="_blank"}. Our payment menu UI is
+currently limited to `nb-NO`, `sv-SE`, `da-DK` `fi-FI` and `en-US`.
 
 ### Monetary Amounts
 

checkout-v3/get-started/setup.md

@@ -48,7 +48,7 @@ with an access token.
 
 How to generate your access token:
 
-**Log in to:** [The External Integration Merchant Portal](https://merchantportal.externalintegration.swedbankpay.com ) - For
+**Log in to:** [The External Integration Merchant Portal](https://merchantportal.externalintegration.swedbankpay.com){:target="_blank"} - For
 testing environment.
 
 **Merchant details:** Here you will find information about your

checkout-v3/get-started/terminology.md

@@ -51,7 +51,7 @@ menu_order: 12
 {:.table .table-striped}
 | **One-phase payment flow**      | A [one-phase][fundamentals] payment is a payment done in one step. The amount is settled in one transactional step.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
 | **Operation**                   | A  payment operation determines what kind of payment that should be implemented. Available payment operations vary, depending on payment method. The most common operation all payment methods share is the Purchase operation. Card Payments have several others, such as [Verify][verify-url] and [Recur][recur].                                                                                                                                                                                                                                                                                                                                      |
-| **Operations**                  | Operations consist of an array of contextual links / actions that direct the payment flow in a given state of the payment resource (i.e. creating a capture transaction, creating a reversal transaction, returning a redirect URL, etc). Operations are [HATEOAS][hateoas] driven and managed through API calls.                                                                                                                                                                                                                                                                                                                                                           |
+| **Operations**                  | Operations consist of an array of contextual links / actions that direct the payment flow in a given state of the payment resource (i.e. creating a capture transaction, creating a reversal transaction, returning a redirect URL, etc). Operations are [HATEOAS][hateoas]{:target="_blank"} driven and managed through API calls.                                                                                                                                                                                                                                                                                                                                                           |
 
 ### P
 

checkout-v3/modules-sdks/development-guidelines/code-of-conduct.md

@@ -9,7 +9,8 @@ menu_order: 900
 It is important that the projects governed by Swedbank Pay foster a
 collaborative, open, inclusive, positive and tolerant community. To underscore
 this, a `CODE_OF_CONDUCT.md` file from
-[Contributor Covenant][contributor-covenant] should be added to the project:
+[Contributor Covenant][contributor-covenant]{:target="_blank"} should be added
+to the project:
 
 ## Contributor Code of Conduct
 
@@ -55,8 +56,9 @@ appropriate to the circumstances. Maintainers are obligated to maintain
 confidentiality with regard to the reporter of an incident.
 
 This Code of Conduct is adapted from the
-[Contributor Covenant][contributor-covenant], version 1.3.0, available at
-[http://contributor-covenant.org/version/1/3/0/][version]
+[Contributor Covenant][contributor-covenant]{:target="_blank"}, version 1.3.0,
+available at
+[http://contributor-covenant.org/version/1/3/0/][version]{:target="_blank"}
 
 The Code of Conduct should then be referenced from the `CONTRIBUTING` file,
 for example with the following paragraphs:

checkout-v3/modules-sdks/development-guidelines/contributing.md

@@ -17,8 +17,8 @@ things you need to know.
 
 ## Getting Started
 
-*   Read and make sure you agree with the [Code of Conduct][coc].
-*   Make sure you have a [GitHub account][github].
+*   Read and make sure you agree with the [Code of Conduct][coc]{:target="_blank"}.
+*   Make sure you have a [GitHub account][github]{:target="_blank"}.
 *   Then, you have three options:
     1.  Submit a ticket for your issue, assuming one does not already exist.
         *   Clearly describe the issue including steps to reproduce when it is a
@@ -32,14 +32,16 @@ If you choose option 3 (forking the repository), then please read on.
 
 ## Making Changes
 
-*   Create a new [branch][branching] from where you want to base your work.
+*   Create a new [branch][branching]{:target="_blank"} from where you want to
+    base your work.
     *   This is usually the `master` or `develop` branch.
     *   Please avoid working directly on the `master` and `develop` branch.
-*   Make [commits][commit] of logical units in the new branch.
+*   Make [commits][commit]{:target="_blank"} of logical units in the new branch.
 *   Check for unnecessary space with `git diff --check` before committing.
 *   Make sure your [commit messages][commit-practice] are well written and in
     the proper format.
-*   [Push][push] the branch to your [forked repository (remote)][remote].
+*   [Push][push]{:target="_blank"} the branch to your
+    [forked repository (remote)][remote]{:target="_blank"}.
 *   Submit a pull request for the pushed branch.
 
 [coc]: /checkout-v3/modules-sdks/development-guidelines/code-of-conduct

checkout-v3/modules-sdks/development-guidelines/good-commit-practice.md

@@ -5,15 +5,15 @@ menu_order: 1100
 ---
 
 The following document is a fork of
-[OpenStack's Git Commit Good Practice][good-practice], rewritten to suit
-Swedbank Pay needs. It is based on experience doing code development, bug
-troubleshooting and code review across a number of projects using Git.
-Examination of other open source projects suggested they all follow a fairly
-common practice. It is motivated by a desire to improve the quality of the
-Git history in any repository. Quality is a hard term to define in computing;
-one person's "Thing of Beauty" is another's "Evil Hack". We can, however,
-come up with some general guidelines for what to do, or conversely what not
-to do, when publishing Git commits for merge with a project. This topic can
+[OpenStack's Git Commit Good Practice][good-practice]{:target="_blank"},
+rewritten to suit Swedbank Pay needs. It is based on experience doing code
+development, bug troubleshooting and code review across a number of projects
+using Git. Examination of other open source projects suggested they all follow a
+fairly common practice. It is motivated by a desire to improve the quality of
+the Git history in any repository. Quality is a hard term to define in
+computing; one person's "Thing of Beauty" is another's "Evil Hack". We can,
+however, come up with some general guidelines for what to do, or conversely what
+not to do, when publishing Git commits for merge with a project. This topic can
 be split into two areas of concern:
 
 1.  The structured set/split of the code changes
@@ -55,9 +55,9 @@ rule:
 *   If a change is found to be flawed later, it may be necessary to revert the
     broken commit. This is much easier to do if there are not other unrelated
     code changes entangled with the original commit.
-*   When troubleshooting problems using Git's [bisect][bisect] capability, small
-    well defined changes will aid in isolating exactly where the code problem
-    was introduced.
+*   When troubleshooting problems using Git's [bisect][bisect]{:target="_blank"}
+    capability, small well defined changes will aid in isolating exactly where
+    the code problem was introduced.
 *   When browsing history using Git annotate/blame, small well defined changes
     also aid in isolating exactly where & why a piece of code came from.