fix: use String.replace() instead of replaceFirst() in createBaseURL

[Vinu2111]

Fixes #1838

What

createBaseURL in Service.java used String.replaceFirst() to swap test URLs
for live URLs. Since replaceFirst() accepts a regex pattern, dots in the URL
strings (e.g. pal-test.adyen.com) were treated as wildcards — matching any
character instead of a literal dot.

Fix

Replaced the affected replaceFirst() calls with String.replace(), which does
plain literal string matching. No regex involved, no wildcard risk.

The following blocks were updated:

• pal- block
• checkout- block (both the /possdk/ branch and the standard branch)
• device-api- block (both EU and non-EU branches)

The two calls without dots (-live → -test and -test → -live) were
intentionally left as replaceFirst() since they are not affected by this issue.

Test

Added testLivePalUrlOnlyMatchesLiteralDots() to ServiceTest.java to verify
that a URL resembling a pal endpoint but without literal dots is not incorrectly
transformed by the pal- block.

[gemini-code-assist]

Code Review

This pull request replaces replaceFirst with replace in Service.java to ensure literal matching of URLs containing dots, and adds a corresponding unit test. The review feedback suggests extending this change to the authe block for consistency and improving the test case to accurately verify that dots are not treated as regex wildcards.

[gemini-code-assist]

While this change correctly fixes the regex wildcard issue for the pal- block, the same issue exists in the authe block (around line 94 in the full file), which still uses replaceFirst() with a search string containing literal dots (https://test.adyen.com/). Please consider updating that block as well to ensure consistent and correct URL transformation across all service types.

[Vinu2111]

Fixed in the latest commit.

[gemini-code-assist]

The test case testLivePalUrlOnlyMatchesLiteralDots does not effectively verify the fix for the regex wildcard issue. The test string https://pal-devXadyenYcom/... would not match the target https://pal-test.adyen.com/... even if dots were treated as wildcards, because dev does not match test. To properly verify that dots are matched literally and not as wildcards, the test should use a string where only the dots are changed, such as https://pal-testXadyenYcom/....

Suggested change

	@Test
	public void testLivePalUrlOnlyMatchesLiteralDots() {
	config.setLiveEndpointUrlPrefix("123456789-company");
	// A URL where dots are replaced with other characters should NOT be transformed
	// by the pal- block. String.replace() does exact literal matching, so a URL that
	// looks like a pal URL but has non-dot separators passes through untouched.
	String urlWithNonDots = "https://pal-devXadyenYcom/pal/servlet/v52/initiate";
	String actualUrl = service.createBaseURL(urlWithNonDots);
	assertEquals(urlWithNonDots, actualUrl);
	}
	@Test
	public void testLivePalUrlOnlyMatchesLiteralDots() {
	config.setLiveEndpointUrlPrefix("123456789-company");
	// A URL where dots are replaced with other characters should NOT be transformed
	// by the pal- block. String.replace() does exact literal matching, so a URL that
	// would match if dots were wildcards (regex) but has non-dot separators passes through untouched.
	String urlWithNonDots = "https://pal-testXadyenYcom/pal/servlet/v52/initiate";
	String actualUrl = service.createBaseURL(urlWithNonDots);
	assertEquals(urlWithNonDots, actualUrl);
	}

[Vinu2111]

Updated the test to use pal-testXadyenYcom so the URL structurally
matches pal-test.adyen.com but with non-dot separators. The expected
value accounts for the final -test → -live fallback.