sveawebpay / php-integration Goto Github PK

In the current situation support SveaWebPay's interface only English coded messages which is pretty bad. Customers who shop at a Swedish online store feel more confident about error messages is in Swedish, especially when the message is for a failed payment.

Notice: Undefined offset: 1 in list($lastname, $firstname)

Works in some cases, some cases not. Why are there different combinations of name formatting? "John Doe" or "Doe John" or "Doe, John" in customerIdentity->fullName?

            if (!empty($response->customerIdentity->fullName)) {
              list($lastname, $firstname) = explode(',', (string)$response->customerIdentity->fullName);
              $order->data['customer']['shipping_address']['firstname'] = trim($firstname);
              $order->data['customer']['shipping_address']['lastname']  = trim($lastname);
            }

Once production credentials are provived in SveaConfig.php it seems putting the code into test mode requires privileges. Preferably that the framework forces the out-of-the-box test credentials automatically and overrides the provided info in SveaConfig.php.

After all these test credentials are provided public.

A human readable error message is missing for the resultcode.
Donating some code below:

        switch ($resultcode) {
          case '1':
            $code = 'REQUIRES_MANUAL_REVIEW';
            $errormsg = 'Request performed successfully but requires manual review from merchant. Applicable paymentmethods: PAYPAL 100 INTERNAL_ERROR Invalid – contact integrator';
          case '101':
            $code = 'XMLPARSEFAIL';
            $errormsg = 'Invalid XML 102 ILLEGAL_ENCODING Invalid encoding';
            break;
          case '104':
            $code = 'ILLEGAL_URL';
            $errormsg = '';
            break;
          case '105':
            $code = 'ILLEGAL_TRANSACTIONSTATUS';
            $errormsg = 'Invalid transaction status';
            break;
          case '106':
            $code = 'EXTERNAL_ERROR';
            $errormsg = 'Failure at third party e.g. failure at the bank';
            break;
          case '107':
            $code = 'DENIED_BY_BANK';
            $errormsg = 'Transaction rejected by bank';
            break;
          case '108':
            $code = 'CANCELLED';
            $errormsg = 'Transaction cancelled';
            break;
          case '109':
            $code = 'NOT_FOUND_AT_BANK';
            $errormsg = 'Transaction not found at the bank';
            break;
          case '110':
            $code = 'ILLEGAL_TRANSACTIONID';
            $errormsg = 'Invalid transaction ID';
            break;
          case '111':
            $code = 'MERCHANT_NOT_CONFIGURED';
            $errormsg = 'Merchant not configured';
            break;
          case '112':
            $code = 'MERCHANT_NOT_CONFIGURED_AT_BANK';
            $errormsg = 'Merchant not configured at the bank';
            break;
          case '113':
            $code = 'PAYMENTMETHOD_NOT_CONFIGURED';
            $errormsg = 'Payment method not configured for merchant';
            break;
          case '114':
            $code = 'TIMEOUT_AT_BANK';
            $errormsg = 'Timeout at the bank';
            break;
          case '115':
            $code = 'MERCHANT_NOT_ACTIVE';
            $errormsg = 'The merchant is disabled';
            break;
          case '116':
            $code = 'PAYMENTMETHOD_NOT_ACTIVE';
            $errormsg = 'The payment method is disabled';
            break;
          case '117':
            $code = 'ILLEGAL_AUTHORIZED_AMOUNT';
            $errormsg = 'Invalid authorized amount';
            break;
          case '118':
            $code = 'ILLEGAL_CAPTURED_AMOUNT';
            $errormsg = 'Invalid captured amount';
            break;
          case '119':
            $code = 'ILLEGAL_CREDITED_AMOUNT';
            $errormsg = 'Invalid credited amount';
            break;
          case '120':
            $code = 'NOT_SUFFICIENT_FUNDS';
            $errormsg = 'Not enough founds';
            break;
          case '121':
            $code = 'EXPIRED_CARD';
            $errormsg = 'The card has expired';
            break;
          case '122':
            $code = 'STOLEN_CARD';
            $errormsg = 'Stolen card';
            break;
          case '123':
            $code = 'LOST_CARD';
            $errormsg = 'Lost card';
            break;
          case '124':
            $code = 'EXCEEDS_AMOUNT_LIMIT';
            $errormsg = 'Amount exceeds the limit';
            break;
          case '125':
            $code = 'EXCEEDS_FREQUENCY_LIMIT';
            $errormsg = 'Frequency limit exceeded';
            break;
          case '126':
            $code = 'TRANSACTION_NOT_BELONGING_TO_MERCHANT';
            $errormsg = 'Transaction does not belong to merchant';
            break;
          case '127':
            $code = 'CUSTOMERREFNO_ALREADY_USED';
            $errormsg = 'Customer reference number already used in another transaction';
            break;
          case '128':
            $code = 'NO_SUCH_TRANS';
            $errormsg = 'Transaction does not exist';
            break;
          case '129':
            $code = 'DUPLICATE_TRANSACTION';
            $errormsg = 'More than one transaction found for the given customer reference number';
            break;
          case '130':
            $code = 'ILLEGAL_OPERATION';
            $errormsg = 'Operation not allowed for the given payment method';
            break;
          case '131':
            $code = 'COMPANY_NOT_ACTIVE';
            $errormsg = 'Company inactive';
            break;
          case '132':
            $code = 'SUBSCRIPTION_NOT_FOUND';
            $errormsg = 'No subscription exist';
            break;
          case '133':
            $code = 'SUBSCRIPTION_NOT_ACTIVE';
            $errormsg = 'Subscription not active';
            break;
          case '134':
            $code = 'SUBSCRIPTION_NOT_SUPPORTED';
            $errormsg = 'Payment method doesn’t support subscriptions';
            break;
          case '135':
            $code = 'ILLEGAL_DATE_FORMAT';
            $errormsg = 'Illegal date format';
            break;
          case '136':
            $code = 'ILLEGAL_RESPONSE_DATA';
            $errormsg = 'Illegal response data';
            break;
          case '137':
            $code = 'IGNORE_CALLBACK';
            $errormsg = 'Ignore callback';
            break;
          case '138':
            $code = 'CURRENCY_NOT_CONFIGURED';
            $errormsg = 'Currency not configured';
            break;
          case '139':
            $code = 'CURRENCY_NOT_ACTIVE';
            $errormsg = 'Currency not active';
            break;
          case '140':
            $code = 'CURRENCY_ALREADY_CONFIGURED';
            $errormsg = 'Currency is already configured';
            break;
          case '141':
            $code = 'ILLEGAL_AMOUNT_OF_RECURS_TODAY';
            $errormsg = 'Ilegal amount of recurs per day';
            break;
          case '142':
            $code = 'NO_VALID_PAYMENT_METHODS';
            $errormsg = 'No valid paymentmethods';
            break;
          case '143':
            $code = 'CREDIT_DENIED_BY_BANK';
            $errormsg = 'Credit denied by bank';
            break;
          case '144':
            $code = 'ILLEGAL_CREDIT_USER';
            $errormsg = 'User is not allowed to perform credit operation';
            break;
          case '300':
            $code = 'BAD_CARDHOLDER_NAME';
            $errormsg = 'Invalid value for cardholder name';
            break;
          case '301':
            $code = 'BAD_TRANSACTION_ID';
            $errormsg = 'Invalid value for transaction id';
            break;
          case '302':
            $code = 'BAD_REV';
            $errormsg = 'Invalid value for rev';
            break;
          case '303':
            $code = 'BAD_MERCHANT_ID';
            $errormsg = 'Invalid value for merchant id';
            break;
          case '304':
            $code = 'BAD_LANG';
            $errormsg = 'Invalid value for lang';
            break;
          case '305':
            $code = 'BAD_AMOUNT';
            $errormsg = 'Invalid value for amount';
            break;
          case '306':
            $code = 'BAD_CUSTOMERREFNO';
            $errormsg = 'Invalid value for customer refno 307';
            break;
          case '307':
            $code = 'BAD_CURRENCY';
            $errormsg = 'Invalid value for currency';
            break;
          case '308':
            $code = 'BAD_PAYMENTMETHOD';
            $errormsg = 'Invalid value for payment method';
            break;
          case '309':
            $code = 'BAD_RETURNURL';
            $errormsg = 'Invalid value for return url';
            break;
          case '310':
            $code = 'BAD_LASTBOOKINGDAY';
            $errormsg = 'Invalid value for last booking day';
            break;
          case '311':
            $code = 'BAD_MAC';
            $errormsg = 'Invalid value for mac';
            break;
          case '312':
            $code = 'BAD_TRNUMBER';
            $errormsg = 'Invalid value for tr number';
            break;
          case '313':
            $code = 'BAD_AUTHCODE';
            $errormsg = 'Invalid value for authcode';
            break;
          case '314':
            $code = 'BAD_CC_DESCR';
            $errormsg = 'Invalid value for cc_descr';
            break;
          case '315':
            $code = 'BAD_ERROR_CODE';
            $errormsg = 'Invalid value for error_code';
            break;
          case '316':
            $code = 'BAD_CARDNUMBER_OR_CARDTYPE_NOT_CONFIGURED';
            $errormsg = 'Card type not configured for merchant';
            break;
          case '317':
            $code = 'BAD_SSN';
            $errormsg = 'Invalid value for ssn';
            break;
          case '318':
            $code = 'BAD_VAT';
            $errormsg = 'Invalid value for vat';
            break;
          case '319':
            $code = 'BAD_CAPTURE_DATE';
            $errormsg = 'Invalid value for capture date';
            break;
          case '320':
            $code = 'BAD_CAMPAIGN_CODE_INVALID';
            $errormsg = 'Invalid value for campaign code. There are no valid matching campaign codes';
            break;
          case '321':
            $code = 'BAD_SUBSCRIPTION_TYPE';
            $errormsg = 'Invalid subscription type';
            break;
          case '322':
            $code = 'BAD_SUBSCRIPTION_ID';
            $errormsg = 'Invalid subscription id';
            break;
          case '323':
            $code = 'BAD_BASE64';
            $errormsg = 'Invalid base64';
            break;
          case '324':
            $code = 'BAD_CAMPAIGN_CODE';
            $errormsg = 'Invalid campaign code. Missing value';
            break;
          case '325':
            $code = 'BAD_CALLBACKURL';
            $errormsg = 'Invalid callbackurl';
            break;
          case '326':
            $code = 'THREE_D_CHECK_FAILED';
            $errormsg = '3D check failed';
            break;
          case '327':
            $code = 'CARD_NOT_ENROLLED';
            $errormsg = 'Card not enrolled in 3D secure';
            break;
          case '328':
            $code = 'BAD_IPADDRESS';
            $errormsg = 'Provided ip address is incorrect';
            break;
          case '329':
            $code = 'BAD_MOBILE';
            $errormsg = 'Bad mobile phone number';
            break;
          case '330':
            $code = 'BAD_COUNTRY';
            $errormsg = 'Bad country parameter';
            break;
          case '331':
            $code = 'THREE_D_CHECK_NOT_AVAILABLE';
            $errormsg = 'Merchants 3D configuration invalid';
            break;
          case '332':
            $code = 'TIMEOUT';
            $errormsg = 'Timeout at Svea';
            break;
          case '500':
            $code = 'ANTIFRAUD_CARDBIN_NOT_ALLOWED';
            $errormsg = 'Antifraud - cardbin not allowed';
            break;
          case '501':
            $code = 'ANTIFRAUD_IPLOCATION_NOT_ALLOWED';
            $errormsg = 'Antifraud – iplocation not allowed';
            break;
          case '502':
            $code = 'ANTIFRAUD_IPLOCATION_AND_BIN_DOESNT_MATCH';
            $errormsg = 'Antifraud – ip-location and bin does not match';
            break;
          case '503':
            $code = 'ANTIFRAUD_MAX_AMOUNT_PER_IP_EXCEEDED';
            $errormsg = 'Antofraud – max amount per ip exceeded';
            break;
          case '504':
            $code = 'ANTIFRAUD_MAX_TRANSACTIONS_PER_IP_EXCEEDED';
            $errormsg = 'Antifraud – max transactions per ip exceeded';
            break;
          case '505':
            $code = 'ANTIFRAUD_MAX_TRANSACTIONS_PER_CARDNO_EXCEEDED';
            $errormsg = 'Antifraud – max transactions per card number exceeded';
            break;
          case '506':
            $code = 'ANTIFRAUD_MAX_AMOUNT_PER_CARDNO_EXCEEDED';
            $errormsg = 'Antifraud – max amount per cardnumer exceeded';
            break;
          case '507':
            $code = 'ANTIFRAUD_IP_ADDRESS_BLOCKED';
            $errormsg = 'Antifraud – IP address blocked';
            break;
          default:
            $code = 'UNKNOWN_ERROR';
            $errormsg = 'Unknown error';
            break;
        }

There is no decimal when doing a recurring transaction.
When i try to charge 12.5 i get back the amount 1250 in the RecurTransactionResponse Object.

When trying to add a FixedDiscount, at least for HOSTED payment types it fails.

This is because of OrderValidator->validateOrderRows, which tries to validate this row as a common order row.

if (isset($row->quantity) == false)

… will cause failure, as the FixedDiscount row has no quantity. Likely some more of the tests in the method will fail as well.

As a side note, the error message is somewhat confusing:

'-missing value : Quantity is required in object Item. Use function Item::setQuantity(). -missing values : At least two of the values must be set in object Item:: AmountExVat, AmountIncVat or VatPercent for Orderrow. Use functions setAmountExVat(), setAmountIncVat() or setVatPercent()'

I just found out the currency for the result parameters fromAmount and toAmount from getPaymentPlanParams() is fixated by the clientNo. This requires internal logic keeping track of which clientNo the integration package made use from during the call.

An additional parameter currencyCode in the result both answers our questions and does most of the work for us.

Fatal error: Class 'SoapClient' not found in D:\inetpub\vhosts\eathome.nu\httpdocs\includes\libs\svea\src\WebService\svea_soap\SveaDoRequest.php on line 26 when calling example/invoiceorder/invoiceorder.php.

Hello,

I'm using the Svea PHP integration kit from Github and trying to create an invoice payment, but I'm getting an error from the server.

Here's the response:

Here's the request (which is well formed by the way):

Since there is no convenient way to mass convert strings I suggest internal support for multiple charsets. Before you send the rendered xml you should easily be able to convert the complete output.

I.e.

if (strtolower($this->charset) != 'utf-8'') $xml = utf8_encode($xml);

The following code shows card and direct bank in the payment gateway. It should only display card:

->usePayPage()
->includePaymentMethods(
PaymentMethod::KORTCERT,
PaymentMethod::SKRILL
)

The following code perfectly shows only direct bank:

->usePayPage()
->includePaymentMethods(
PaymentMethod::DBNORDEASE,
PaymentMethod::DBSEBSE,
PaymentMethod::DBSEBFTGSE,
PaymentMethod::DBSHBSE,
PaymentMethod::DBSWEDBANKSE
)

I know this is a warning but it should be handled

Can be reproduced by following:

$Order = WebPayAdmin::queryOrder($aConfig);
$Order->countryCode = 'SE';
$Request = $Order->setOrderId(590177)->queryCardOrder();
$Info = $Request->doRequest();

Warning: Division by zero in /src/HostedService/HostedResponse/HostedAdminResponse/QueryTransactionResponse.php on line 225

getTestConfig() or getProdConfig() does not resolve what pay page credentials should be used if the customer is identified by e.g. country US.

I am informed this is registered as an issue in you backlog. But I would like to open a github ticket so there is something I can follow.

PS: Clients complain SveaConfig.php is messy and difficult to ride if you are not a developer. It's neither obvious to them to scroll down a page to edit additional credentials for production.

Hello,

I want to give a users a "free month" when ordering a recurring product and i need the user to complete the card payment so i can get a subscription id, but it seams that i cant redirect user to card payment form if the charge price is zero.

I was informed by Anders that setCurrency() in createOrder has no purpose. Because the order currency is controlled by the clientNo.

May I ask why we are calling this function in the first place if we do not benefit from the behavior from it?

[question] Dear Sveawebpay Team.

I can´t find which currency is supported for each payment method? I can assume that this is 'DKK' // Danish Kroner, 'EUR' // Euro, 'NOK', // Norwegian Kroner, 'SEK' //Swedish Kronor for PaymentMethod::KORTCERT since these are the supported countries, but can´t be 100% sure for other payment methods. Is this listed somewhere?

Still getting notices from the latest build of this morning.

Notice: Undefined property: stdClass::$CampaignCodes in ~/Response/WebServiceResponse/PaymentPlanParamsResponse.php on line 23

Notice: Trying to get property of non-object in ~/Response/WebServiceResponse/PaymentPlanParamsResponse.php on line 23

Warning: Invalid argument supplied for foreach() in ~/Response/WebServiceResponse/PaymentPlanParamsResponse.php on line 23

I assume this occurs every time no campaign codes are returned.

Support for SOAP client proxy would be nice.

I assume useInvoicePayment() now routes through either SOAP or REST (PayPage) depending on the set of country? Especially out of the problematics mentioned in issue #14.

"As a store owner point of view you want sales quick. Every middle step in a checkout process is a risk of stepping out."

Since international direct invoices are not supported in SOAP a pay page is the only destination? While routing through the pay page it seems the setPayPageLanguage() is not supported through useInvoicePayment(). I'm using config file for authetication and the latest master.

Fatal error: Call to undefined method InvoicePayment::setPayPageLanguage()

I assume the need to solve the logic is what makes us have to separate the behaviors for creating an order using the SWP framework.

However I find the two methods individualCustomer() and companyCustomer() possible to merge.

A universal method could something like this:

Proposal:

->addCustomerDetails(
Item::Customer()
->setTaxId("000000-0000")
->setCompanyName("ACME Inc.") // Required if TaxId validates as comany
->setName("John", "Doe")
->setCoAddress("c/o Simpsons")
->setStreetAddress("Street", 7)
->setZipCode(9999)
->setLocality("Timbuktu")
->setEmail("[email protected]")
->setIpAddress("0.0.0.0")
->setPhoneNumber(081234567)
)

Hypothetical changes from merging individualCustomer() and companyCustomer():

• - setCompanyIdNumber - Replaced by TaxId
• - setVatNumber - Replaced by TaxId
• - setSsn - Replaced by setTaxId
• + setTaxId
• - setInitials - Removed, instead extract the first character of the first and last word/name in "Vincent van Gogh"
• - setBirthDate - Can be extracted from TaxId if validated as an individual
• * SetCompanyName - If set, triggers isCompany
• * setStreetAddress - Accepts both ("Gatan 23") or ("Gatan", 23)

Benefits for the store / user-end:

• Removes the logic needed to separate a company from an individual.
• Removes the logic needed to separate 23 from "Gatan 23".
• Removes the logic needed to extract or keep track of birthdays.
• Removes the logic needed to separate SE19000000000001 from 000000-0000.
• Removes the need to keep track or solve the logic for initials.

How to tell if a swedish tax Id is a company or individual.
http://sv.wikipedia.org/wiki/Organisationsnummer

VATIN formats
http://en.wikipedia.org/wiki/VAT_identification_number

If birthdays cannot be extracted from NL or DE individuals Id-numbers I suppose the setBirthDate must stick.

Thoughts?

Since rest of the form stuff is available in rawFields, HostedRequests/Helper/PaymentForm.php could use htmlFormAction and htmlFormMethod too.

I understand the difference between the two options SVEAINVOICEEU_SE and SVEAINVOICESE. One is the SOAP API and the other is the hosted pay page gateway REST API. One performs on the fly with and the other one not. One requires all necessary information, the other one not. And so on...

As a store owner point of view you want sales quick. Every middle step in a checkout process is a risk of stepping out. But from a programmer point of view you want things nice, consequent, clean, and tidy.

For national sales the obvious choice of use is SVEAINVOICESE. But to handle international sales SVEAINVOICEEU_* is the only inconvenient option. This is where a programmer and store owner starts to disagree. The result would be a combination of the two methods and hopefully the programmer is paid the overtime.

One of the noted purposes of the integration package is to eliminate the need of separate codes due to the combination of two API technologies. But I think this still needs a lot of thinking. Escepcially since invoicing is the main product by SWP.

I propose som more dynamics to this thing.

My proposal is letting the SWP framework do more of the logic.

1. Prepare order
2. Select Invoice
3. Do we have enough information for performing a SOAP order?
4. a. Yes, make a SOAP call and simulate the REST return URL as $destination.
5. b. No, make a REST call use the real redirect url for $destination.
6. Make the redirect to $destination
7. Verify result - universal handler
8. Success

The current reasons for using the paypage instead of direct invoice in the above would then be:

• If not SE
• If not enough customer information.
• (What else didn't come to my mind.)

Having country set to SE and using usePayPageDirectBankOnly() I recceive the following error:

Error: Unknown error (Code: 142)

And the alternative way which worked previously before the renaming:

->usePayPage()
  ->includePaymentMethods(
    PaymentMethod::BANKAXESS,
    PaymentMethod::NORDEA_SE,
    PaymentMethod::SEB_SE,
    PaymentMethod::SEBFTG_SE,
    PaymentMethod::SHB_SE,
    PaymentMethod::SWEDBANK_SE
  )

Same thing returns:
Error: Unknown error (Code: 142)

Instead of downloading a tar I would be more convenient to update and key up with the latest and greatest using Composer.

The address response differs in case to case. I am having slight frustration separating firstname from lastname.

From a test environment:

fullName = "Persson, Tess T"

From a production:

fullName = "Lastname Middlename Middlename Firstname"

To shrink the amount of logic needed to handle names. I strongly suggest separating firstname(s) from lastname:

I.e.
firstName = Tess T
Lastname = Persson

Or if possible:
firstName = Tess Jane
spokenName = Tess
lastName = Doe

It's easier to glue these together if needed than separating them. The sometimes returning coma and sometimes not requires extra logic. The middle name(s) or initials that sometimes is present is trouble for a regular explode(' ', $fullname) or explode(', ', $fullname) and needs a lot of extra logic. Not to mention what happens with surnames with prepositions such as von/de/van etc I.e. Vincent van Gogh.

Let's invent convenience rather than inconvenience. :)

I am in deep need of a solution how to solve the logic for turning the given address string examples below into street name + house number:

Stora gatan 5
Stora gatan 5 C
Stora gatan 5 C 2tr
Stora gatan 5C BV

I cannot see the benefits on having this left to be head ache for the implementer.

Got any prewritten code that does the trick?

I strongly suggest this is handled inside the integration package as I have not stumbled upon a single platform that keeps track of the two parameters separately. And there is no magic rule to preg_replace the string.

There should be a function to get the payment plan sum for product pages in the api.

I am sending a bit of criticism when it comes to (un)conventional payment flows and operations.

Problem 1:
While initiating a card transaction we are asked for the orderId in setClientOrderNumber(). If the user presses the Cancel button or go "javascript:history.go(-1)" the orderId is blocked for any transaction completion and completely locked out from reselecting card payment. Now SWP did activate a tweak to recover from a clicked Cancel button. But it doesn't solve the browser back button which is a conventional method in any browser to go back to a previous page.

If we append a timestamp to the orderId we lack the ability to match our database with your database.

Problem 2:
Unconvetionally while canceling a card payment, instead of being redirected back to checkout. It seems setCancelUrl() is ignored. Instead the user is redirected to order processing which fails with the error Cannot be verified - Canceled.

Here's my implementation for getting the form needed for a hosted payment:

require_once('./sites/all/modules/sveawebpay/lib/src/Includes.php');

// Initialize a new order.
$order = WebPay::createOrder();

$order->setTestmode();

// Various settings.
$order
  ->setCountryCode('SE')
  ->setCurrency('SEK')
  ->setClientOrderNumber($txn->txnid); // $txn is the transaction object.

// Add order items.
foreach ($txn->items as $item_id => $item) {
  $order->addOrderRow(
    Item::orderRow()
      ->setQuantity($item->qty)         // Quantity.
      ->setAmountIncVat($item->price)   // Price.
      ->setVatPercent(0)                // VAT.
      ->setName($item->title)           // Title.
  );
}

// Method.
$form = $order->usePayPage()
  ->setMerchantIdBasedAuthorization($merchant_id, $secret)
  ->getPaymentForm();

print $form->completeHtmlFormWithSubmitButton;

This is creating the next form:

<form name='paymentForm' id='paymentForm' method='post' action='https://test.sveaekonomi.se/webpay/payment'>
<input type='hidden' name='merchantid' value='XXXX' />
<input type='hidden' name='message' value='PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHBheW1lbnQ+CiA8Y3VzdG9tZXJyZWZubz40NjwvY3VzdG9tZXJyZWZubz4KIDxyZXR1cm51cmwvPgogPGNhbmNlbHVybC8+CiA8YW1vdW50PjcxMDA8L2Ftb3VudD4KIDxjdXJyZW5jeT5TRUs8L2N1cnJlbmN5PgogPGxhbmc+ZW48L2xhbmc+CiA8b3JkZXJyb3dzPgogIDxyb3c+CiAgIDxkZXNjcmlwdGlvbj48L2Rlc2NyaXB0aW9uPgogICA8bmFtZT5Qb3dlclBvaW50IDIwMDggZm9yIE1hYyBEVkQgKEluY2x1ZGVzIFNvZnR3YXJlIEFzc3VyYW5jZSkgKEVuZ2xpc2gpPC9uYW1lPgogICA8c2t1Pjwvc2t1PgogICA8YW1vdW50PjcxMDA8L2Ftb3VudD4KICAgPHF1YW50aXR5PjE8L3F1YW50aXR5PgogIDwvcm93PgogPC9vcmRlcnJvd3M+CjwvcGF5bWVudD4K' />
<input type='hidden' name='mac' value='e28fb3fa3020ee60332d1af5009704120646efd81125ae7c8aaf16d8483ed04537a83faee6379b42e09edd7bf134f2cb6c96353ce706310002ab3ab84e2b9457' />
<noscript><p>Javascript is inactivated in your browser, you will manually have to redirect to the paypage</p></noscript>
<input type='submit' name='submit' value='Submit' />
</form>

After submitting, I'm getting 136 (ILLEGAL_RESPONSE_DATA) at https://test.sveaekonomi.se/webpay/payment.

What I have done wrong? Or did I missed something?

Probably missing, since other ones contain it.

If i use the WebPay::createOrder()->addOrderRow() method i get the following (Also please note that i have used setName & setDescription)

How come that the "NumberedOrderRow" doesn't show "name" when i send it in?
If i send in only name it goes straight into "description".

Svea\NumberedOrderRow Object
(
       [creditInvoiceId] => 
       [invoiceId] => 
       [rowNumber] => 1
       [status] => NotDelivered
       [articleNumber] => 
       [quantity] => 1.00
       [unit] => st
       [amountExVat] => 159.2
       [vatPercent] => 25
       [amountIncVat] => 
       [name] => 
       [description] => Quantum of Solace (Blu-ray): prod_prod-s1/84
       [discountPercent] => 0.00
       [vatDiscount] => 0
)

Svea\OrderRow Object
(
       [articleNumber] => 
       [quantity] => 1
       [unit] => st
       [amountExVat] => 159.2
       [vatPercent] => 
       [amountIncVat] => 199
       [name] => Quantum of Solace (Blu-ray)
       [description] => prod_prod-s1/84
       [discountPercent] => 0
       [vatDiscount] => 0
)

Fatal error: Call to undefined method Svea\HostedService\ListPaymentMethods::setCountryCode()

The class "HostedRequest" is clearly missing setCountryCode, and so is "ListPaymentMethods"

According to : http://sveawebpay.github.io/php-integration/#i66
This is breaking current implementations!

Instead of manually picking each payment method as of today's date available for a certain type. It would be convenient to just select a group. That way whenever new banks or cards are supported under the account they would automatically list in the paypage.

I.e.

PaymentMethod::ALL_CARD (Certitrade, Dancard etc)

PaymentMethod::ALL_DB (all direct banks)
PaymentMethod::ALL_DB_SE (all direct banks in SE)

From Response/WebServiceResponse/PaymentPlanParamsResponse.php:

foreach ($message->GetPaymentPlanParamsEuResult->CampaignCodes->CampaignCodeInfo as $code) {

If an error is returned, no CampaignCodes are returned and PHP will complain.

Add VATIN formated ssn to the list of accepted ssn formats.

Example:
SE19460509222201

These seem okay:
4605092222
460509-2222
194605092222
19460509-2222

When i use doRecur() i get a fatal error:
Call to undefined method Svea\HostedService\RecurTransaction::setCurrency()

if (empty($response->accepted)) return array('error' => 'Payment transaction was not accepted');

The line causes card/bank transactions fail saving as an order. Is it an error, or is there a documentation somewhere to what to use instead in the latest bundle of the integration package?

( ! ) Fatal error: Class 'Svea\AdminService\WebServiceRowFormatter' not found in /var/www/.../svea/AdminService/CreditOrderRowsRequest.php on line 47

And when i fix that i get this one

( ! ) Fatal error: Class 'Svea\AdminService\CreditOrderRowsRequest' not found in /var/www/.../svea/BuildOrder/CreditOrderRowsBuilder.php on line 211

It would be nice to have public methods that expose the calculated total amounts of the currently added rows, to be able to find differences between a store and svea, minimizing total discrepancies

Right now i loop through all rows and add things together, would be better to have it right on the integration package

We have the ability to authorize via MerchantId by following the documentation. But all of the possible places in the code commented out now. Should this be so? Some confusion has arisen around the configuration. Could you clarify this point?

My client wants to preset setInvoiceDistributionType for the order without delivering the invoice. The reason is because my client collects the choice of e-invoice or paper invoice in the session during checkout.

From my understanding this is not possible in WebPay::createOrder(), so how do we do it? And shouldn't this setting be a part of useInvoicePayment()?

For deprecated methods or method name changes, leaving a working reference can prevent critical operations from not halting.

I.e.

function setSsn($input) {
  trigger_error('The method '. __METHOD__ .' is deprecated. Use setNationalIdNumber() instead.', E_USER_DEPRECATED);
  return $this->setNationalIdNumber($input);
}

Here's only the XML (->xmlMessage) part of what I'm sending to a hosted payment. I'm using the master branch as codebase.

<?xml version="1.0" encoding="UTF-8"?>
<payment>
 <customerrefno>98</customerrefno>
 <returnurl>http://example.com/sveawebpay/success</returnurl>
 <cancelurl>http://exampe.com/sveawebpay/cancel</cancelurl>
 <amount>7100</amount>
 <currency>SEK</currency>
 <lang/>
 <orderrows>
  <row>
   <description></description>
   <name>My product name</name>
   <sku></sku>
   <amount>7100</amount>
   <quantity>1</quantity>
  </row>
 </orderrows>
 <paymentmethod>KORTCERT</paymentmethod>
</payment>

The problem is that when I hit "Cancel" (AVBRYT) on the hosted payment form (at https://etest.certitrade.net/card/paywin/index) I'm redirected to <returnurl> instead of <cancelurl>. It's true that I'm getting 108 (CANCELLED) there. Is this the normal behavior? Or is it -> setCancelUrl() deprecated?

If i use the WebPay::createOrder()->addOrderRow() method and add Shipping/Invoice-products they don't get added.
But if i use WebPayAdmin::addOrderRows(...)->addOrderRows() it will be added

IndividualCustomer::setSsn() is the correct method.

A few wishes from our side:

1. Write in English. We have international customers, and the more information that is available to everyone, the better.
2. If you can: Make a fork, create a failing test case for your issue, possibly with a fix for the issue, and send us a pull request. This is probably the fastest way to get a problem fixed.
3. Provide as much relevant data as possible. This will speed up our handling of the issues. BUT BE CAREFUL: Don't provide passwords or secret words here. Relevant data is things like version of the code, stack traces, and such.

Thanks!

In case of a SoapFault exception, the library dumps out the last request, which could cause leaking of sensitive information, such as username and password.

From WebServiceRequests/svea_soap/SveaDoRequest.php:

         } catch (SoapFault $fault) {
            print_r($this->client->__getLastRequest() . "<hr />" .
$fault->getMessage());
            die();
         }

I get this error message when trying to query an order:

SoapFault: Server did not recognize the value of HTTP Header SOAPAction: http://tempuri.org/IAdminService/GetOrders. in SoapClient->__soapCall() (line 61 of /src/AdminService/admin_soap/SoapClient.php).

Receiving "Invalid country code" for DK or FI when using ->useInvoicePayment().

Other countries might be returning the same error as well.

Using latest master.

For stores with international sales, it would be very convenient if a simple check with the framework could be done, asking if the session customer can use sveawebpay for checkout BEFORE even rendering the checkout option.

Proposal example:

$result = WebPay::checkAvailability()
->setPaymentMethods(...)
->setCurrency("GBP")
->setCountry("GB")
->setLanguage("en")
->doCheck()

// should we continue displaying the checkout option?
// ...

Otherwise one would always have to manually check if i.e. the currency is within the allowed list of currencies. When sveawebpay expands and adds support for new countries, these statements would manually need to be edited in each and every customer installation.