You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
$mpay24->refund(‘00000000000’, ($amount * 100));
// Übergeben wird nun zwangsläufig ein float, aber halt ohne Nachkommastellen
public function setAmount($amount)
{
$this->amount = (int)$amount;
// $this->amount ist nun 1789
}
Das ist wie es bei den Gutschriften zum Rundungsproblem kam. War halt völlig unerwartet und tauchte beim Test nicht auf, denn interessanterweise gibt es Beträge wo das nicht passiert. 25,90 => kein Problem. 19,20 => kein Problem. 17,90 => Problem!
Natürlich kann man dem entgegenwirken indem man schon vorher einen Integer übergibt. Aber vielleicht wäre in den Funktionen die den Amount annehmen die Erwartung einen Integer zu erhalten besser als es nachher zu typecasten:
/**
* @param int $amount
*/
public function setAmount(int $amount)
{
$this->amount = (int)$amount;
}
The text was updated successfully, but these errors were encountered:
The real question is who is responsible to converting the value into an integer. IMHO this is the integrator.
We only guarantee that the value will be sent to the API as an integer value.
If done right this should work. A quick possibility is to add a fraction
Bug reported by Leonidas D.
mpay24-php / src / Requests / ManualCredit.php
Methode setAmount():
Das TypeCasting das hier via (int) stattfindet kann zu unerwarteten, forcierten Rundungsergebnissen führen, zumindest wo ich es getestet habe.
https://stackoverflow.com/questions/20758881/why-is-php-typecasting-behaving-like-this-int-mis-rounding-numbers
So z.B. ein Fall mit:
$amount=17.90;
// $amount ist hiermit ein float
$mpay24->refund(‘00000000000’, ($amount * 100));
// Übergeben wird nun zwangsläufig ein float, aber halt ohne Nachkommastellen
public function setAmount($amount)
{
$this->amount = (int)$amount;
// $this->amount ist nun 1789
}
Das ist wie es bei den Gutschriften zum Rundungsproblem kam. War halt völlig unerwartet und tauchte beim Test nicht auf, denn interessanterweise gibt es Beträge wo das nicht passiert. 25,90 => kein Problem. 19,20 => kein Problem. 17,90 => Problem!
Natürlich kann man dem entgegenwirken indem man schon vorher einen Integer übergibt. Aber vielleicht wäre in den Funktionen die den Amount annehmen die Erwartung einen Integer zu erhalten besser als es nachher zu typecasten:
The text was updated successfully, but these errors were encountered: